






'ittk ! ^S, -•!'••+ »Ar''^Vv»i’* » '* '!&' SfjT'^.f' 












1218 32 



NAVAL 



POSTGRADUATE SCHOOL 

Monterey, California 




THESIS 



A PROGRAM MANAGER'S METHODOLOGY 
FOR DEVELOPING STRUCTURED DESIGN 
IN EMBEDDED WEAPONS SYSTEMS 

by 

James I. Ransbotham, Jr. 
and 

Donald F. Moorehead, Jr. 
December 1983 



i Thesis Advisor: Ronald W. Modes 

Approved for public release; distribution unlimited 



security CLASSiriCATlON OF THIS PACE (Wffn Dmtm Entmrmd) 



REPORT DOCUMENTATION PAGE 


READ INSTRUCTIONS 
BEFORE COMPLETING FORM 


1. REPORT NUMBER 


2. GOVT ACCESSION NO. 


3. RECIPIENT’S CATALOG NUMBER 


4. TiTLt (and SubtHU) 

A Program Manager's Methodology for 
Developing Structured Design in 
Embedded Weapons Systems 


5. TYPE OF REPORT 4 PERIOD COVERED 

Master's Thesis 
December 1983 


6. PERFORMING ORG. REPORT NUMBER 


7. authow.; 

James I. Ransbotham, Jr. 
and 

Donald F. Moorehead, Jr. 


8. CONTRACT OR GRANT NUMBERr*; 


S. PCNFONMINO OROANIZATION NAME AND ADDRESS 

Naval Postgraduate School 
Monterey, California 93943 


10. PROGRAM element. PROJECT, TASK 
AREA 8 WORK UNIT NUMBERS 


11. CONTROLLING OFFICE NAME AND ADDRESS 

Naval Postgraduate School 
Monterey, California 93943 


12. report date 

December, 1983 


13. NUMBER OF pages 

14 3 


MONITOPING ACEnCY name & AOORESSr/l /rom Controlling Offic*) 


15. SECURITY CLASS, (ot thit rapori) 

UNCLASSIFIED 


Mm. DECLASSIFICATION/DOWNGRADING 
SCHEDULE 


IS. DISTRItUTION STATEMENT (ot thlt R»pdrl) 

Approved for public release; distribution unlimited 



17. OISTfllRUTlON STATEMENT (oi th 0 mbmtrsct «nt«r«d In Block 30, U dlUcrmu from Rmpott) 



It. SUPPLEMENT ARY NOTES 



19. KEY WORDS (Contlnum on rovcrco cldo If noccocsrr Idonttiy by block numbmr) 

Methodology, Embedded Weapons Systems, Structured Design 



20. ARSTRACT (Contlnum on rovormo old* If n*e***sfy *nd tdonilfy by block numbmr) 

This thesis demonstrates a methodology to be used by a Program 
Manager to allow him to procedurally monitor the design develop- 
ment of an embedded weapons system. The methodology consists of a 
unique combination of several software engineering strategies 
integrated to form a powerful management tool. The primary 
objective of the methodology is to provide an algorithmic pro- 
cedure which stresses simplicity (Continued ) 

DD I JAN*?] 1473 COITION or 1 NOV •> IS OCSOLCTC 

S/N 0J02- LF-OU-6601 1 



SECUNITY classification OF TmS PAGE flWi.n 




I 



I 



security classification of this page ( Wh 9 it Dmf Enffd ) 



ABSTRACT (Continued) 

at all levels o£ abstraction. Further, the system must be 
capable of generating good system specifications, good documenta- 
tion, and fully understandable products. Sample products from 
the implementation of the methodology on the HARPOON Shiboard 
Command- Launch Control Set (HSCLCS) are provided for illustrative 
purposes . 



S-N 0102- LF-0I4- 660I 



2 SECURITY CLASSIFICATION OF THIS PAGEfWft«n Bnt9fd) 



Approved for public r9leas9; distribution unlimited. 



& Prograii Manager* s Methodology 
for Developing Structnred Design 
in Embedded fleapons Systems 



by 



James I. Ransbothaa , Jr. 
Lieutenant comman'’d9r. United States Navy 
B.S., Georgia Institute of Technoloay, 1972 



and 

Donald ?. Moorehead, Jr. 
Lieutenant Commander, United States Navy 
B.S., U.S. Naval Academy, 1975 



Submitted in oartial fulfillment of the 
requirements for the degree of 

MASTER OP SCIENCE IN COMPUTER SCIENCE 

from the 

NAVAL POSTGRADUATE SCHOOL 
December 1983 






^ 2 , 7 / / 



ABSTRACT 



r> 



*.A 



This thesis demonstra-s s a methodology to be used by a 
Program Manager to allow him zo procedurally monitor rhe 
design development of an embedded weapons system. The merh- 
odology consists of a unique combination of several software 
engineering strategies integrated to form a powerful manage- 
ment tool. The primary objective of the methodology is to 
provide an algorithaic procedure which stresses simplicity 
at all levels of abstraction. Further, the system must be 
capable of generating good system specifications, good docu- 
mentation, and fully understandable products. Sample prod- 
ucts frcm the implementation of the methodology on the 
HARPOON Shipboard Command-Launch Control Set (HSCLCS) are 
provided for illustrative purposes. 
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I. INTRO DPC TIOW 



2. BICKGBOOHD 

Project Management within the Navy involves the 
coordination of a ccmplex set of managerial and technical 
responsibilities. The complexity is the result of such 
factors as the diversified areas in which a Program Manager 
must become competent and the size and complexity of modern 
weapons systems. The task is aggravated and the problems 
magnified by several facrors including schedule limitaticns 
and resource scarcity (human, monetary, procedural manage- 
ment tools, etc). Because the current institutionalized 
procedures are inadequate, a Program Manager has insuffi- 
cient tangible guidelines to organize a project in a way 
which will counter and mitigate complexizy. 

As a consequence, most projects suffer increasing inef- 
ficiency which is paralleled by a rise in disorganization. 
This is a sure result of unccntrolled ccmplexiny. One of 
the more notable areas of inefficiency is in the process of 
specifying the desired system. Our current "methodology" 
all too often generates nebulous and inaccurate system spec- 
ifications. This situation begins a snowball effect of 
increasinc ambiguity as contractors, bidding on the project, 
attempt tc design a system to meet specifications which may 
not be complete or correct. Therefore, contractors are 
forced to react to the assumed meaning of poor specifica- 
tions rather than acting toward generating a clear, logical, 
and correct design. This approach to generating specifica- 
tions generally results in the contractor's proposals not 
meeting the user's real need. Hopefully, problems are 
discovered early; the later they surface, the higher the 
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these undetected 



cost to correct them. At best, however, 
flaws cause the needless loss of much time and money (after 
the project is given tc a contractor) regardless of when 
discovered. 

Tc summarize, complexity is inherent but controllable in 
all projects. We currently do very little in attempting tc 
control it. The resulting disorganization leads to time and 
money losses mainly due to poor specifications. 



E. PURPOSE 

This thesis presents a procedural methodology for an 
embedded weapons system's specif icatior. development and 
design documentation, answering the need defined in the 
previous section. The method is abstracted from a case 
study of the Harpoon Shipboard Command-Launch Control Set 
system development initialized by Sentman and Marcney 
[Ref. 1 ] and refined by Olivier and Olsen [Ref. 2]. It is 
our intenticn to show that by using this methodology, 
complexity will be reduced and the following improvements to 
embedded weapons system procurement will be realized: 

1. better specifications generated, 

2. better evaluation of contractor's proposals, 

3. increased efficiency within the project manager's 
office, 

4. better pass down information available to the project 
manager's relief, and 

5. development costs lowered. 



C. SCOPE OF THE BETHCDOLOGT 



The methodology discussed in this thesis is intended to 
apply to the development of all embedded computer systems 
for tactical weaponry. The possibility for a broader scope 
exists sines the underlying principles are widely 
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applicabls. Howsvsr, further genaralizing of the method- 
ology is net appropriate at this time since the case srudy 
only addressed a tactical weapons embedded computer sys-em. 

Figure 1. 1 shews the placement of the Software 
Engineering Methodology within the initial weapons sysrem 
procurement phase. Figure 1.2 details the general flew of 
control wirhin the Software Engineering Methodology. This 
figure also shows that while the Contractor Support Services 
(CSS) Contractor develops the specif ications and other prod- 
ucts, the Program Manager lends guidance to and approves the 
final products of this process. The guidance supplied is of 
a managerial and not a technical nature. Since our handling 
of the methodology is concerned with the technical issues of 
how the procedures should be performed, the thrust of cur 
discussion will be aimed at the CSS System Development block 
of Figure 1.2. 

D. HETHCDOIOGY 0?EEVIEW 

It was cur determination that the system design method- 
ology, while generally only an abstraction from the case 
study, must possess several broad traits in order to meet 
the objectives stated in the Purpose, Section B. Where 
these traits were not innate in the abstracted procedures, 
the methodology was refined to encompass them. These traits 
are introduced below. The Conclusions portion of this 
thesis. Chapter 5, discusses why each of these traits is 
necessary and how they permeate the methodology. 

1. Simplicity. Simplicity of the methodology and in the 
understanding of its goals and products is necessary. 
Unless a system is simple, it has great potential to 
become part of the complexity problem rather than 
part of its solution. 
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Figurs 1.1 Prograa aaaageaent High Level Flow Chari:- 
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Figure 1.2 Detail cf ths Software Engiueeriug aethcdology . 
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2. Generator of Good System Specifications. The menhcd- 
olcgy must produce firm, finely-tuned, and in-hcuse 
system specifications. None that the term in-house 
refers to the project being directly supsrvis<=d by 
nhe Program Manager regardless of where the actual 
work is performed. To be mosr effective, however, 
rhe actual work should be done in the same general 
location as the Program Manager (i.e. the same 
office, office building, or group of buildings). 
This assumes that it is necessary to have physical 
closeness of the Program Manager and the project 
designer in order to achieve their continual and 
effective communication. 

3. Generator of Good Documentation Products. The meth- 
odology must produce products which serve as a proper 
passdown to reliefs of the Program Manager and his 
staff memebers. If design decisions and system spec- 
ifications are not properly documented, corporate 
knowledge will surely be lost upon job turn-over. 

4. Generator of Understandable Products. The method- 
ology must produce products which require little 
formal training to understand and use. Also it must 
be couched in terminology easily absorbed by the 
average Program Manager. 

To ensure that these broad system traits are achieved, 
the methodology must yield products which possess several 
specific features, inter -alia understandability , reli- 
ability, efficiency, and modifiability. These are the major 
goals of all software engineering design methods. To 
achieve these specific goals, the software must adhere to 
many structural principles. Ross, Goodenough, and Irvine 
[Ref. 3] provide the following list of required principles: 
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1. Mcdularity. The modulari-ry principle defines how zo 
structure a software system appropriately. 

2. Abs-raction. The a bsrracrion principle helps iden- 
tify essential properties common to superficially 
different entities. 

3. Localization. The localization principle highlights 
methods for bringing relared things into physical 
proximity . 

4. Hiding. The hiding principle highlights rhe 

importance of making nonessential implementation 
infcrmarion inaccessible. It enforces constraint on 
access to information, 

5. Uniformity. The uniformity principle ensures consis- 
tency. 

6. Completeness. The completeness principle ensures 
nothing is left out. 

7. Confirmability. The confirmability principle ensures 
that information needed to verify correctness has 
been explicitly stated. 

The methodology must meet the goals and objectives detailed 
above and roust possess the listed traits. It must also 
adhere tc all of the principles of software engineering 
design strategies. Only by religious adherance to these 
crireria can the complexity of designing a ractical weapons 
system be significantly reduced. 

There is one fundamental premise of this methodology 
imperative to its success: the system software development 

must hold tcp priority with hardware issues being deferred 
until the system specifications are completed. In other 
words, rhe software decisions must drive the hardware selec- 
tion. This premise has been reiterated and subst ant iar ed by 
numerous case studies performed in recent years among them 
Barry Boehm’s ’’software first machine” [Ref. 4]. In view of 
the fact that the amount of computer development money spent 
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spam: on hardware. 



cn software is several times the amount 
this is a logical prioritization of project emphasis. 

The basis for rhe above premise is that, in order to 
meet the goals of reliability, modifiability, maintain- 
ability, and to a large degree porrability in software, it 
must be procedurally developed independent of and without 
regard for the hardware on which it will execute. k major 
source of frustration and inefficiency for programmers and 
maintainers of current ractical weapons system software is 
that the hardware is ingrained in and an inflexible part of 
the system. Consequently, all modifications to the software 
must be couched in the limitations of the system hardware, 
limitations which often require that software modifications 
disregard all principles of software engineering. If the 
reverse process, that of allowing the hardware to drive the 
software, is used, these hardware deficiencies are quickly 
realized. When this occurs, the potential for maintaining 
the desired goals specified above is greatly reduced. 

Holding off on the hardware specification until the 
methodology is completed is not an unrealistic proposal. 
This is especially true in light of the high frequency of 
hardware change and upgrade which most weapons system 
projects experience. The basic idea is simple: it is rela- 

tively easy to find shelf hardware to implement a software 
system while the difficulty of achieving the design goals 
listed above on a specified piece of hardware is at best 
unpredictable. 

A standard argument against having the software drive 
the hardware is that there are many hardware systems 
purchased (one per platform) but only one software system. 
This basically implies that cost savings are more a function 
of hardware than sof'tware. This argument could be valid if 
no modifications to the software, which destroy its struc- 
ture, were required. But the probability of achieving this 
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ever the system's life cycle is incredibly small, 
structure is destroyed, the future system costs, ev^n in 
disccunted or constant dollars, »ould invariably ba many 
times the initial cost savings in hardware. 

Prior to initiating the procedures of the methodology, 
the Procram Manager along with his staff must become 
familiar with the current project documents and the specific 
purpose and mission of the weapons system. The first step 
is to become intimately familiar with the Eroaa 
S -acif ications detailed in the Life Cycle Management 

Milestone Zero documentation, the Justification for Major 
System New Start (JMSNS) . These broad system requirements 
are developed based on a projected mission need by 
Deoartment of the Navy planners. In-house refinement of 
these Broad Specifications due to changing needs, technical 
advancements, and inputs from the fleet (the user group) 
produces a set of Initial Functional Specifications. Next 
the Initial Functional Specifications are used as the input 
to the methodology to design the proposed system utilizing 
the .rinciples of software engineering. Again Figure 1.1 
provides a graphic representation of this flow. 

Three disjoint items are pertinent to the overall view 
of the methodology in this stage of the system development. 
First, the system design is most likely being performed by a 
Contractor Support Service (CSS) firm. This is because the 
Proaram Manaoer nor his staff have the time and in many 
cases the ability to perform these tasks. Second, this CSS 
firm is effectively part of the Program Office. It should 
not be theught of as a separata entity but rather as a tech- 
nical representative augmenting the Program Manager's staff. 
This closeness ensures that the Program Manager's desired 
sstem will be generated. Third, the products produced by 
the system are generated and updated iteratively (see Figure 
1.2). This continual refinement of the products ensures 
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qcod docunenta t ion of the perceived system. These items of 
note must be fully comprehended by the Program Manager in 
order to most effectively utilize the methodology. 

There are four ourput products generated and refined by 
usina this methodology: a detailed ssr of sysrem specifica- 

tions (the final Refined Specifications) , complete Data Flow 
Diagrams and Hierarchy Charts, the designed system in ADA 
System Desian Language (SDL) with Module Descrip tions , and 
Desian Decision Documentation (see Appendices A-E which show 
these products for the HSCLCS design) . Collectively they 
provide all the documentation required to perpetuate the 
cor-orate memory of the project and to give a complete 
picture of the proposed system. Individually they provide 
the following functions; 

1. Svstem Specifications. These are the detailed speci- 
fications delivered to project bidders responding to 
the request for proposals. The higher the level of 
refinement of the specifications when entering this 
ohase of weapons system development, the better the 
chances are that bidders will develop sound system 
oroposals to meet the real need. 

2. Data Flow Diagrams (DFD) and Hierarchy Charts. These 
orcducts provide a graphic display of th= system by 
illustrating the system functional operation. Using 
only the functions to be performed and the input and 
output data needed to perform these functions, DFD's 
and Functional Hierarchies are simple to generate and 
use. 

3. Design in ADA SDL With Module Descriptions. The 
design provides a procedural-level illustration of 
the system. It documents how the required functions 
shewn in the DFD’s are transposed into a hierarchy of 
procedures, fuctions, and tasks for data manipulation 
in order to perform these functions. 

1 9 
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. Design Decision Documentation. While mosn design 
decisions appear in ether documents (i.e. the speci- 
fications, design, etc.), some are not feasibly 
includable in ether preduens. The Design Decision 
Documentation provides a place to snore perninent 
facts and parameters of the system. 

Thus far in this section we have dealt with the neces- 
sary goals, principles, and requirements of the Software 
Engineering Methodology box of Figure 1,1 and not the 
mechanics of the system. This is because the high-level 
view of the methodology must be one of achievement of design 
objectives and not in the procedures necessary to produce 
documents. Whether or net these objectives are met will be 
the subject of Chapter 5, Conclusions. However, to provide 
a proper overview of the methodology details Figure 1.3 is 
included as an illustration of the iterative product formu- 
lation phase. The detailed discussion of this flow and its 
subgoals is the sole subject of Chapter 4. 
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figure 1.3 Detail of the CSS System DeTelopmeut, 
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II. BflCKGROOND OF THE HARPOON CONTROL SCT DESIGN 



Recently when the missile subsystem cf the HARPOON 
Weapon System was upgraded to include two new block enhance- 
ments, the existing HARPOON Shipboard Command-Launch Control 
Set (HSCICS) was rendered inadequate to support rhe design 
features of the new blocks cf missiles. Upon exarainatxon by 
analysts, it was decided that the existing HSCLCS software 
was not modifiable and a new design effort was necessary. 
The new design would need to not only cover the recent 
missile changes but also be fexible enough to be modified to 
support anticipated technical achievements in rhe near 
future. This chapter will introduce the basic facets of rhe 
HARPOON Weapon System and provide background on rhe work 
done in two previous theses, [Ref. 1] and [Ref. 2], reward 
redesign of the HSCLCS. 

A. EXISTING HARPOON WEAPON SYSTEH 

The HARPOON Weapon System (HHS) has been developed to 
fulfill the requirements of the Navy's anri-ship mission. 
The HWS is currently deployed on surface ships, submarines 
and aircraft. The HWS provides over the horizon anri-ship 
capability in all wearher, day or night. The HWS is 
comprised of the missile, launcher, and com mand- launch 
subsystems. The ship-launched HARPOON employs either 
onboard or third parry sensor dara for targeting informa- 
tion. The missile is a "launch and forget" weapon, since no 
ship control or information is needed after launch. 

Fcr surface ships, the HWS control and data processing 
functions are provided by the HSCLCS which has three modes 
cf operation: normal, casualty and training. In the normal 
mode the major functions cf the HSCLCS are; 
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1. Distribution cf pows r to various HWS equipaiant. 

2. Selection and application of missile warmup power. 

3. The ability to conduct various automatic and manually 
initiated tests which confirm the operability of the 
system. 

4. Distribution cf ship motion data from ship equipment. 

5. Selection, transfer, processing and display of target 
data . 

6. Coordination cf the selection of the tactical missile 
mode and type of fusing. 

7. Selection of the launcher cell containing the 
intended missile to be launched. 

8. Initialization of the seiectad missile and the super- 
vision of the exchange of data between missile and 
other HWS equipment. 

9. Control of all missile firing activities. 

These functions are implemented and integrated by the 
HARPOCN Weapon Control Indicator Panel (HWCIP) and the 
HARPOON Weapon Centre! Console (HWCC) . 

The HWCC contains most of the HARPOON system-unique 
command and launch subsystem equipment, including the Data 
Processor Computer (DPC) , the Data Conversion Unit (DPU) and 
the HWCC life support equipment. Together these components 
perform data processing and conversion among various data 
types and provide interfacing with existing sensor and 
ship’s equipment. 

The WCIP provides visual status information to the oper- 
ator during formulation of the fire control problem, and 
additionally provides manual controls for the operator. The 
existing WCIP is shown in appendix E. 

The DPC is a 16-bit microcomputer with 15K of SPHCM. 
The DPC uses an assembly language program to provide the 
follcwing: 
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1. Launch envelops para merer validation. 

2. Missile command generation for implementation of 
missile control parameters including ship's attitude, 
search pattern orders, engine starting, flight termi- 
nation range, altimeter setting, and various selec- 
table flight trajectory and maneuvering modes. 

3. Pre-launch testing. 

4. Pre-launch sequencing and timing. 

5. Data formatting and transfer synchronization. 

The DCQ processes all digital and analog signal conver- 
sions as required by installed hardware. The DCU also 
provides interfacing of target data inputs from the Naval 
Tactical Data System (NTDS) Slow Interface. Ship motion 
parameter data is also converted in the DCU. 

E. PBOBIEBS iSSOCIAIED WITH EXISTING HSCLCS 

Since the existing software of the present HSCLCS is 
written in assembly code and is heavily hardware dependent, 
the maintenance cost in the face of periodic missile changes 
is relatively high. Also several different hardware config- 
urations exist for tre different firing platforms. 

The HSCLCS also has numerous deficiances in engagement 
planning as the operator cannot fully control the features 
of the new block missiles. In fact, the operator has no 
automated assistance in engagement planning in the current 
system, and there is no display of the tactical situation at 
the WCIP. The current firing solution does net have environ- 
mental factors included unless the operator considers them 
manually. On some platforms NTDS was inrended to provide the 
services mentioned in most of these deficiencies but the 
location of the WCIP has inhibited this effort and indeed 
many HAHPOON platforms do net have NTDS! 
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C. BABPOON WEAPON SYSTEM CONSTRAINTS 

The constraints in this saction are for tha most part 
technically oriented. Managerial constraints are to be 
determined by competent authority at a later date. The 
upgrade cf the HSCLCS must be able to support the new block 
missiles as well as the old ones since the old missiles will 
be in the fleet for some time. 

The implementation of the upgrade must continue to 
provide all previous factions as wall as interfacing with 
NTDS. The existing launcher hardware will remain the same 
and the physical size of the HSCLCS must be the same. 

While the DPU hardware configuration cannot change, the 
DPC software is subject to change as necessary to implement 
the upgraded HSCLCS. although tha current software is in 
assembly language, this is not a requirement for the 
upgrade. System reliability of the upgrade must meet or 
exceed existing standards for the HSCLCS. 

D. SYSTEM DEFINITION FOR HSCLCS UPSRADE 

A detailed discussion of the system definition for the 
upgrade can be found in [Ref. 1 ]. It is summarized below. 

The hardware of the system will change significantly. 
The existing DPC will be replaced with a commercially avail- 
able CPU with additonal memory. The WCIP will be modified to 
include a display which shows the current tactical situation 
and programmable software keys to control both the display 
and engagement planning features which will be incorporated 
into the DPC software. A hook and cursor similar to those 
in NTDS will also be provided at the WCIP for the operator.' 
A display processor will be attached to the WCIP . The DCU 
hardware will remain the same however the software must be 
changed to accommodate new inputs from NTDS and environ- 
mental data. 
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The software upgrade of tha DPC which is the major part 
of the HSCLCS focused upon by this rhesis is to eliminate 
the existing deficiencies mentioned in rhe section B of this 
chapter. Specifically, a software plan must be developed 
which produces adequate software that provides required 
capabilitit ies and is flexible enough in design to be modi- 
fied in the future with minimum amount of blood and tears. 

E. STATE 0? THE OPGBABE 

The software upgrade of the HSCLCS has been the subject 
of the two previously referenced theses. The initial thrust 
of the first thesis by Maroney and Sentman was to develop a 
software plan. Figure 2.1, and complete the first three 
phases. Emphasis was placed on good software engineering 
techniques. A systems requirements analysis was conducted 
which produced revised system specifications and laid the 
foundation for the preliminary design. Data flow diagrams 
and subsequent transform analysis techniques described in 
[Ref. 5] were used. ADA was chosen as the system design 
language in anticipation of its proclamation as the standard 
DOD SDL and because it lends itself so well to the modu- 
larity concepts necessary for modular design. 

The second thesis by Olsen and Olivier continued the 
software development by deriving a preliminary design from 
the products of Maroney and Sentman. To continue the plan, 
a final design must be completed along with detailed docu- 
mentation. This final design process is described in the 
methcdolccy chapter. 
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III. SOFTi&RE ENGINEERING SNaPSHOT 



The need for good software engineering rechniques has 
hecome increasingly evident in the past decade with the 
exponential growth of software development and maintenance 
costs. Since necessity is the mother of invention, the 
number of new software engineering methods and techniques 
has also grown exponentially. The major contributors to the 
methodology of this thesis. Pressman, De Marco, and Bcoch, 
all have derived systems for software design using their own 
particular styles. In this chapter we will briefly discuss 
those styles and alsc comment on some other software design 
methodologies. 

Structured design was first publicized by Yourdon and 
Contantine [Ref. 6], It was developed to be used as the 

transition tool between Structured Analysis and actual 
imole me ntation . Composed of various concepts, measures, 
rules of thumb, and analysis techniques, this method with 
early development by Ee Marco is the basis for the Pressman 
design methodology. 

In fBef. 7], De Marco describes the life cycle of a 
software project from requirements analysis to specifica- 
tions. After an initial survey of systems requirements, a 
data flow analysis is conducted using data flow diagrams. 
The next step involves creating a data dictionary from the 
data identified in the data flow analysis. At this point in 
De Marco's methodology, the data flow diagrams are trans- 
lated into a set of specifications using a subset of English 
called Structured English. Structured English is a 
specification language that makes use of a limited vocabu- 
larv and a limited syntax. The vocabulary consists of 
imperative verbs, terms defined in the Data Dictionary, and 
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certain reserved words for logic formation. The mapping of 
the data flew analysis to the Structured English specifica- 
tions is fairly algorithmic but uses several heurisnics that 
will not be discussed here. De Marco also explains rhs 
desired traits of a design based on the specifications 
generated, but does not include a procedure for realization 
of the design. 

Pressman, [Bef. 5], elaborates on all phases of the 
software life cycle ana gives several different approaches 
to design such as data flow oriented design and data struc- 
ture oriented design. In both of these areas he carries the 
software development process through the preliminary design 
phase but does not address specification generation. The 
data flow analysis of Pressman resembles that of De Marco 
but his transform/transaction analysis which leads to module 
hierarchy charts contibutes significantly to design 
realization. 

The object oriented design menhodology of Booch [Saf. 8] 
concerns the development of design after some sort of data 
analysis has been conducted. Booch doss not indicate a 
preference as tc whether data flow diagrams or any other 
kind of analysis identifies the objects in a project as long 
as the method is complete. After objects are identified and 
given attributes, this methodology develops a system design 
by stepwise refinement of a simple prose description of the 
system. This prose eventually is transformed into ADA 
system design language. No guidance for conversion of the 
ADA SDL tc structured system specifications is given in this 
metho dology . 

There are several system analysis and design tools that 
have teen inplemented but have not gained wide-spread use. 
SADT (a trademark of SOFTECH, Inc) is a system analysis and 
design technique developed within the Ycurdon organization 
that is used as a tool for system definition, software 
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requirements analysis, and system design. The me'^hodoicgy 
encompasses technical tools and a well-defined organiza- 
tional harness through which the tools are applied. An 
automated requirements analysis tool is SHEM [ Ref. 5], 
where elements, attributes, relarionships , and structures 
(all parts of the Requirements Statement Language (RSL) ) are 
combined tc form the details of the requirements specifica- 
tion. SEEM was initially designed for embedded computer 
systems and requires a software support package called REVS 
which uses computer graphics and reports on information 



flow . 


Still 


another automated too 


1 is CADSAT 


(Compu 


ter-Aided Design and Specification 


Analysis Tool) 


which 


with PSL/PSA 


provides an analyst with 


several capabil- 


ities . 


These include: 




1 . 


description 


of information systems. 


regardless of 




application 


area. 




2. 


creation of 


a data base containing 


descriptors for 




the informa 


ticn system. 




3 . 


addition , 


deletion, and modification 


of descriptors. 




and 






4 . 


product ion 


of formatted documented and various 



reports on the specification. 

CADS AT does not present a panacea but it does provide 
benefits that include documentation quality, easy cross 
reference of documents, easy modification, and reduced main- 
tenance costs. The major disadvantage of most of these 
automated systems is that they require a considerable amount 
of trainirg in order to be used effectively. However, the 
concept of automated design is here to stay because the 
benefits far outweigh the disadvantages. 

The methods described above are only a few of the many 
ways that software development is being conducted today. 
The design tools such as decision tables, flow charts, 
HIPO-charts, structured flow charts, and program listings 
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this thesis tc 



discuss 



abound. It is outside the scope o 
in detail all of the methodologies, bur each one is based on 
the design principles outlined in this rhesis. If each 
methodology produces results with the desired characreris- 
tics, only through extensive experience can one judge- the 
relative efficiency cf the methodologies. Since software 
engineering is still at the fledgling stage, we can only 
hope that rhese methodologies will mitigate the software 
crisis. 
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11 . DESIGN SETIODOLOGT 



The methodology for refining embedded computer weapons 
sysrems specifications, which is the subject of nhis 

chapter, is required to possess an algorithmic form and 
logical design an all levels. By levels we mean the levels 
of abstraction from which the methodology can be viewed. 
For example, an outsider to the project office would view 
the methodology as a "black box" which inputs broad specifi- 
cations and fLeen criteria and outputs final design specifi- 
cations and refined design products (see Figure 1.1). The 
Program Manager would be heavily involved in the iterative 
refinement of the system specifications and products and 
consequently would see the methodology as a generation and 
refinement tool. His "black box" would be the Contractor 
Support Services (CSS) System Development block of Figure 
1.2. Finally, the CSS Contractor would view the methodology 
as an algorithm for production. This algorithmic flew is 
shown in Figure 1.3. These are proper abstractions for the 
methodology; they optimally map the responsibilities of each 
of the individuals into their required level of concern for 
detail. 

This chapter is concerned with rntroducing a methodology 
at the CSS Contractor level which embraces all of the goals 
and principles and proper trade-offs of Software Engineering 
design. This level can be viewed as the bottom of the 
abstraction hierarchy because it is the lowest level at 
which the entire design is still within view. It is our 
belief that if this level of the design methodology is 
well-structured and simple then the entire hierarchy will be 
sc. This hypothesis will be further developed in Chapter 5. 



32 



The methodology, ax. the level specified above, was 
conceived and tuned using the following pair of guiding 
rules; it must have a simple, sequential form and it niusx 
support a data transform driven design. By data xransform 
driven design we mean that xhe products of design musx 
project hew a datum is interrelated to other data and how 
data is transformed as processes act upon it. The reasons 
for these basic requirements are the subject of the two 
subsequent paragraphs. The achievement of the first 
requirement is best revealed by an illusxraticn; Figure 4.1 
serves this purpose. Notice on this diagram that the flow 
is characterized by singular inputs and outputs with a 
processing block between then. This by definition is the 
simplesx form of sequential flow, thus the first rule is 
satisfied. Figure 4.1 additionally shows that the first 
step of the methcdolcgy or what we will henceforth refer to 
as the first methodology func*:ion is to manipulate the spec- 
ifications into Data Flow Diagrams. This function, data 
flow analysis, strictly follows De Marco’s procedure 
[Ref. 7], a procedure which fully incorporates the criteria 
for data transform driven design listed in the definition 
above. It follows that the second rule is additionally 
satisfied. 

There are several strong reasons for requiring a method- 
ology with simple, sequential flow. For example, the usage 
of such a methodology is straight-forward and easily 

grasped. Further, this type of flow tends to be highly 
logic rather than heuristic oriented. But the chief reason 
we wanted simple, sequential flow was to have a structure 
which readily supported cur methodology model. This model 
views the system as a series of functional mappings, e.g. 
data flow analysis is a function mapping specifications into 
a hierarchy of Data Flow Diagrams (see Figure 4.1). The use 
of the werd function is not intended to imply that the 
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products, i.s, the Data Flow Diagrams, produced by the meth- 
odology are themselves unique; rhe mapping is not 
one-to-one. However, we suggest than each of our method- 
ology functions map their input produce into a small set of 
output products which is a realistic partition of all 
possible output products. By realistic partition we mean an 
equivalence subset cf the output products which contains 
only those products having all of the desired structure 
principles but which omits those grossly inefficient repre- 
sentations of the solution. The benefit cf this terminology 
is it enables the reader to view the methcdology frcm a 
familar technical vantage. Using the terminology we intro- 
duce our hypothesis that these functions retain the proper- 
ties of the input products by transmitting them to the 
output products. In other words the methodology functions 
are designed to ensure that the good initial structure is 
carried forward throughout the methodology. 

The main reason for requiring the methodology to use 
data driven design was based on the fact that real-time 
systems (all applications of our methodology will be real- 
time systems) are easiest to design this way. Shcoman 
[Ref. 9] supports this hypothesis. We decided on data flow 
design because the graphical nature of the data flew model 
supports DeMarco's [Bef. 7] belief that all products of 
analysis functions should be graphic. 

The procedures of the methodology represent the compila- 
tion of related work performed by several distinguished 
pioneers in the field of software engineering. But the 
overwhelming majority cf contributions came from three indi- 
viduals; De Marco; Pressman; and Booth. While each cf these 
men see the problem in the same basic light, they have chan- 
neled their research efforts into different facets of the 
problem. The De Marco contribution consists of a method for 
transferring system specifications into a set of structured 
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products. Data Flow Diagrams, which represent a graphic 
solution to the specification requirements. Pressman 
details a procedure, transform/transaction analysis, for 
creating an abstracted hierarchy of context-independent 
modules, a Function Hierarchy, from Data Flow Diagrams. 
Booch, claiming to have achieved objecx oriented design 
[Ref. 8], contributes a method for developing a final design 
given a Function Hierarchy. It will be shown later that the 
Booch procedure is in fact an object oriented design tech- 
nique. Figure 4.2 illustrates the specific areas of method- 
ology coverage by each of the authors. Fortunately for our 
purposes, these areas of specialization correspond to one or 
more of the specific functions in our methodology such that 
all of them (except Specifications Refinement which is our 
contribution) have been significantly researched. Thus only 
the structural interfaces between the various contributors 
need to be specified before reducing the methodology to a 
series of independent functional units (see section B) . 

The effcrt required to structurally interface between 
the contributors is minimal. On the surface this may appear 
puzzling in light of the complexity normally encountered 
when synthesizing a complete product from disjoint pieces. 
But because each of the contributors used the same generally 
accepted product formats at the interface points, these 
problems were not present. No interface is required between 
the De Marco and Pressman portions of the Methodology. This 
is because Pressman uses all of the rules of De Marco to 
produce Data Flow Diagrams, the input to his transform/ 
transaction analysis. Consequently, we can view this situ- 
ation as if De Marco and Pressman "collaborated'* on the 
interface. Nor is ar interface between Pressman and Booch 
required. The portion of Booch* s method we use requires 
only a function hierarchy as input. Since this is the 
output product of Pressman, no structural interface speci- 
fied by the methcdolcgy is needed. 
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HETHCDOLOGT CEITEBIA 



1 • Goals and P r incipl es 

The goals for the software produced by the method- 
ology (understandability , reliability, efficiency, and modi- 
fiability) are generally accepted by software engineers as 
those of primary importance. In general, this list encom- 
passes all of the relevant attributes necessary to ensure 
than software will realize its minimum life-cycle cost. 
These goals are defined as fellows: 

1. Underst an dabi lity . Undersran dability is that peren- 
tial for software to project a clear and logical 
meaning. It is achievable in all systems regardless 
of the complexity if both the srrucrure and the level 
of abstraction are appropriate for the proposed 
application. It must be stressed that both of these 
properties are needed. Having merely a formatted 
structure yields a legible but complex product. In 
order to realize any of the other goals, understand- 
ahility is paramount. 

2. Reliability. Reliability is the ability of the soft- 

ware to function, under all conditions, as the speci- 
fications intended. It can be thought of as freedom 
from anomolies as well as the absense of blatant 
mistakes. Reliability also encompasses error 

recovery, the ability of the program to continue 
processing in the event of non-catastrophic system 
failure. Achievement of total reliability is 
extremely difficult to prove even in a system 
strictly adhering to software engineering principles. 
It is impossible to prove software reliability under 
lesser conditiens. 

3. Efficiency. Efficiency, as a structure-driving goal, 
is wrong. Hewever, blatant inefficiency makes a 
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sys-em impractical. The efficiency balance must be 
achieved by first adhering to all ocher goals and 
then screening for gross inefficiencies which car. be 
corrected by encapsulating and modifying inefficient 
modules. This is supported by Belady and Lehman 
[Hef. 10] who state that global optimization is not a 
practical objective, but that by locally optimizing, 
global sub-optimization can be achieved. Thus effi- 
ciency should be deferred until a solid system struc- 
ture is established. 

4. Hodi fiability . Modifiability is a broad term which 
encompasses the ability to easily change software for 
enhancements or errors, for performance tuning, and 
for subsetting. The achievement of modifiability is 
difficult because the effects of change are very hard 
to predict. Thus modifiability, more than any other 
goal, universally requires the strict adherence to 
all of the software engineering principles. 

To meet these design goals, the principles addressed 
in Chapter 1 (modularity, abstraction, hiding, localization, 
uniformity, completeness, and confirmability) are the 
primary attributes required of the methodology products. It 
seems apparent from cur readings that among the seven prin- 
ciples, modularity and abstraction are uniformly accepted as 
the dominant r e quiranents cf all software. This is not 
surprising considering that these software qualities, which 
logically reduce larce problems into manageable s ubprobleais , 
are the most effective reducers of complexity. These two 
principles are highly coupled; one abstracts to reduce 
complexity by modularizing and modularizes by performing a 
series of logical abstractions. Thus they should be thought 
of as iterative subprocesses of some higher level generic 
design process. A more detailed description cf the 
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requirements and specifications to benchmark the achievement 
cf modularity and abstracricn are given below: 

1. Modularity. As srated above, ir is nearly impossible 
to address modularity as a stand-alone principle. In 
its simplest form, however, modularity can be consid- 
ered achieved when the solution ~o rhe problem is 
reduced to a hierarchy of separately addressable 
modules. In order for this hierarchy to approach rhe 
optimal solution, though, it must have a good balance 
between two inversely proportional measures; the 
decree of module complexity and the degree cf inter- 
face complexity. 

2. Abstraction. Abstraction, too, is not an independent 
concept. It can be considered achieved when the 
problem has been iteratively expanded (or stepwise 
refined) such that each of the abstraction levels has 
a solution representation which captures the essense 
of the system at this level, but specifies no unnec- 
essary complicating details. These levels of 
abstraction provide an intellectually graspable view 
of the problem’s solution. 

Of the remaining principles required of the method- 
ology the most important ones are completeness, indepen- 
dence, and hiding. While the presentation of these 
principles may tend to imply that they are of second echelon 
order, this is not true. Rather they complete the system of 
interwoven requirements of the methodology. The reason 
these principles are presented separately is because unlike 
modularity and abstraction these concepts are not univer- 
sally accepted in name or in their definition by the 
contributors. Yet each of them is either directly stated or 
indirectly supported as method requirements. For example. 
Pressman stresses module independence, a concept which 
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requires modularity, abstraction, and completeness as prere- 
quisite principles. Thus Pressman must indirectly support 
these structural concepts. Further, he requires the 
simplicity of module interface in his independence concept. 
This is actually a loose form of the hidinq principle. The 
key point, however, is that his method builds a structure 
which allows hiding to be efficiently appended to the set of 
principles across the interface with the Booch method. From 
a broad scope this implies that the method embraces a more 
stringent set of principles at each method interface ulti- 
mately yielding a design which adheres to all of the neces- 
sary structure principles. This idea is developed in the 
next subsection. The specifications for achievement of 
these three additional concepts are given below: 

1. Completeness. Completeness, a principle stressed by 
De Marco, is a critical property of the products of 
our methodology. Its criticality is especially 
apparent when performing the first function, data 
flow analysis. It is mandatory tc ensure that each 
system specification is appropriately captured in at 
least one Data Flew Diagram. If the first procedure 
of the methodology produces a complete set of Data 
Flow Diagrams then all subsequent steps will have a 
good, graphical representation of the requirements by 
which to benchmark. Thus achievement of completeness 
requires the assurance that each methodology function 
carries forward all of the information from the input 
product into the output product. 

2. Independence. Independence, the chief principle 
stressed by Pressman, becomes an important concept 
wken developing the Function Hierarchy. The degree 
of module independence can best be qualitatively 
measured by first measuring the levels of cohesion 
and coupling of the modules. Cohesion is the measure 



41 



of module single -mi ndadness [Ref. 5]. The highesz 
cohesion, which is the goal state for maximizing 
independence, is achieved when every module has a 
single function. Coupling is the measure of module 
interconnec ticn and interdependence [Ref. 5]. The 
lowest coupling is realized when the interfaces 
between modules are simplest. Lew coupling is also 
required to achieve modular independence. Thus inde- 
pendence is achieved when the design products have 
modules which address a specific subfunction of 
requirements and has a simple interface when viewed 
from other modules. 

3. Hiding. Hiding, a principle developed by Parnas and 
highly stressed in the Booch method, implies the 
prerequisite achievement of completeness, modularity, 
abstraction, and independence. An expansion of the 
requirements of independence that distinguishes 
hiding as a more powerful concept is that these 
single function modules must have a simple interface, 
the interface must be the only part of the module 
visible to other modules, and how the function is 
accomplished within the module must be hidden 
[Ref. 11]. This invisibility of module internal 
information takes us one step beyond what these other 
four principles provide: design decision encapsula- 

tion. Therefore, achievement of hiding requires a 
conscious effort by designers to delay design 
decisions until the latest possible time and when 
decisions are made they must be encapsulated and 
concealed in the structure of the design. 

Tim Rentsch has boldly defined the requirements of 
the nebulous procedure termed object oriented design 
[Ref. 12]. He states that the essense of this concept is an 
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adhsrenc® to the principles of abstraction, information 
hiding, decision encapsulation, and modularity. Using his 
definition we can conclude two interesting facts. First, 
the Booch method, as Bocch himself claims, is object 
oriented design. Second, our methodology, because of its 
strong adherence to the five major structure principles, is 
also an example of object oriented design. As the software 
"buzz wcrd" of the 1980' s, object oriented design will 
undoubtedly be a must in DO D software by the 1990 's. 

2 • Pri nci ple Set Synth esi s 

New that all cf the design conceprs required in the 
methodology have been formally presented, it is necessary to 
show how they are related to the methodology functions. 
This includes determining the point at which each of these 
principles becomes an active concept in the design. The 
synthesis idea cf this subsection refers to the fact that 
all of the individual principles are not uniformly visible 
throughout every function of the methodology. They have a 
point at which they become necessary and are thereafter 
carried forward in the principle set. This idea that 
concepts once incorperated in the design are thereafter 
ingrained in its structure is justified in Section C of this 
chapter. 

To realize a principle an the optimum time in the 
design, the structure must be capable of supporting the 
inclusion of the new concept. A rather simple way of 
viewing this requires one to visualize the principle to be 
added as needing a set of prerequisite traits. Fcr example, 
the prerequisites for independence are completeness, 
abstraction and modularity. Thus, if the current structure 
cf the design contains the prerequisite traits then the 
structure will be capable of supporting the new principle. 
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Escaus® the set of principles oehaves in the manner 
stated atcve, the structure re guirems nrs become increasingly 
more stringent as the design is refined. This is the 
desired effect because the ultimate objective of the method- 
ology is to produce a design which encompasses all of the 
software traits but maintains its flexibility as long as 
possible. 

The initial principle set for the methodology 
contains the concepts of abstraction and completeness. It 
is easy to see abstraction as a necessity because each of 
the functions iteratively refines its products and the 
refinement process is based on levels of abstraction. 
Completeness across all of the interfaces requires nc expla- 
nation; without all of the parts, the design could not be 
correct. At the first interface, the DeMarco/Pressman junc- 
tion, the structure must be able to support the addition of 
modularity. The fact that modularity is required at this 
point in the design is no surprise considering that the 
purpose of the Pressman function is to modularize. The 
second and subsequent iterations of the module heirarchy 
continually refine the design structure to achieve low 
module coupling and high module cohesion. When a satisfac- 
tory trade-off between coupling and cohesion is made, inde- 
pendence of modules is achieved thus appending independence 
to the set of principles. With the set of principles now 
containing all the prerequisites, the Pressman/Booch inter- 
face structure is capable of supporting hiding. Figure 4.3 
illustrates the synthesis of the principle set. 

3. HETHCDOIOGY COMPCNENTS 
1 . Data Plow An alysis 

Data flow analysis is the first facet of the evalua- 
tion and synthesis phase of the software csquirements 
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Figure 4.3 Illustration of the Principle Sat Synthesis. 
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determination process. 3y examining the data flow we get 
the big picture on what the entire sysrem receives as input 
and produces as output and the path that data follows in the 
system to be designed. Dana flow is our analysis snart 
point because we do not want to get bogged down in specific 
areas of a system trying to define functions which may not 
be clear in the initial analysis. Dana flow, on the ether 
hand, is usually much easier to identify than flow of 
control, which in most large scale projects is very complex. 
The primary tool we will use to examine the data flow will 
be the Data Flow Diagram (DFD). In nhis section we will 
briefly describe how to build a DFD summarizing the methods 
detailed in [Ref. 5] and [Ref. 7] and also what the DFD can 
give to the Program Manager. We will also introduce a set 
of example DFD's from the HSCLCS system that will be used as 
a case study to illustrate the methodology components 
throughout the chapter. 



Data Flow Diagram Definition 



The data flow diagram is a graphical aid for 
depicting the data flow of the software system being 
designed. A complete understanding of the DFD is imperative 
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1. Data flows represented by an arrow or vector from the 
source of the data to the destination. 

2. Processes represented by circles or "bubbles". 

3. Stored information (e.g data bases or files) repre- 
sented by two horizontal parallel lines with a mean- 
ingful label. 

4. Data sources and sinks represented by boxes. 

Data flow can be broadly defined as information 
flowing between two processes or between a process and a 
source or a sink. There are several general rules 
concerning data flow. 

1. Data flow names are hyphenated and capitalized. 

2. No two dara flows have the same name. 

3. Choose names that describe rhe data explicitly cut be 
concise . 

4. Data flow should not represent a flow of control. 

5. Data flow is^ not considered a process activator. 

Processes invariably show some amount of work 
performed on data. Mere explicitly, a process is a transfor- 
mation of incoming data flow inxo outgoing data flow. Each 
process bubble should be numbered and given a unique 
descriptive name. 

Sources and sinks increase the readability of 
the DFD by showing where the net inputs to the system come 
from and where the net outputs go to. Sources and sinks 
differ from files and data bases in that they are considered 
to be cut of the context of the system. Thus, they show how 
the internal system relates to the outside world. Figure 
4.4 is the source/sink diagram for the Harpoon System 
Command-Launch Centred System (HSCLCS). 
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t. DFD Construction 



The first point to keep in mind during rhe data 
flow analysis is not to try to learn everything at one rime 
about the whole system. Think top down by conceptualizing 
the high level data flew first, defering the development of 
the low level data flow. Especially avoid addressing any 
implementation details at this time and be flexible enough 
in your thought process to start over from scratch if road- 
blocks are encountered. Remember the data flow analysis 
process is iterative. 

The primary input to the data flow analysis is 

the Broad Specifications of the system to be designed. 

Direct liaison with the Program Manager and prospective 
users may also provide additional information. A key point 
to remember during each phase of the methodology is that 
decisions concerning design that are not specifically 

addressed in the Broad Specifications must be documented at 
the point of the decision. These design decisions will 

later be used to update the Broad Specifications. 

To start the process, identify all net input and 
output data flows and list them around the border of your 
working paper. This step is importanr because it is at this 
point that you define the context or scope of the analysis 
to be conducted. Data flow outside of the scope defined 
here will never be addressed again. 

Filling in the DFD is the next step of the 
process. What you try to do is put lines in your diagram 
depicting data flow and try to connect them with circles or 
"bubbles'* where a data transformation occurs. You can start 
from the inputs, outputs or in the middle whichever is the 
most cbvicus development for you. Insure flow of data goes 
from left to right for ease of reading and avoid looping 
back to the left. If a loop appears necessary, duplicate 
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the process bubble that is looped to in order to keep the 
data flow moving right. Do not cross lines and defer naming 
the bubbles until later. When all of the data flows are 
connected then examine each bubble to determine if some data 
flow occurs within a bubble to achieve the bubble output. 
If so, then break down the bubble into subprocesses and 
create lines for the new data flows discovered. If ycur 
working paper is getting flooded with lines at this point, 
it may be time to consider a leveled DFD approach. 

Basically with the leveled DFD the first sheet 
of working paper contains the set of lines and bubbles that 
were thought of on the first cut while subsequent sheets 
contain the internal development of bubbles that were deter- 
mined to contain internal data flow. The leveled DFD system 
enforces top-down data analysis for large systems which in 
turn naturally induces modularity in system design develop- 
ment. Figure 4.5 is an example of a first cut system DFD. 
For convention purposes the bubble which spawned the 
internal data flows will be called the parent and the 
bubbles that result are called children. For numbering 
clarification a child is always given a unique number which 
is prefixed by the parents bubble or process number. As a 
correctness check, always be sure the inputs and outputs of 
the children correspond to those of the parent and vice 
versa. It is also wise to only expand one bubble at a time 
to insure continuity of thought. Data bases and files 
accessed or modified by a bubble should appear on the high 
level diagram with the parent and the appropriate lower 
level diagram with the child. To be sure, upon further 
analysis a child may develop children of its own and in this 
way various levels of a system would be created. Figure 4,6 
shows how one bubble of the HSCLCS was decomposed to form 
new levels. Note that this particular example does not 
balance parent and child inputs and outputs; so further 
refinement is required to capture the correct data flow. 
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after your paper is filled with lines and 
you should label the data flows. Make sure rhe 
names of the data flows are honesr, concise and descriptive. 
Be careful not to grcup disparate items together into one 
data flow when they have no business being treated as a 
whole. If the name is not very obvious, it is possible that 
you need to repartition or break down the flow into levels. 
The naming process is designed to help you catch errors in 
your data analysis so be prepared to back up and reconsider 
at this pcint. 

After the data flows are appropriately labeled, 
it is time to label and number the process bubbles. Use 
similar guidelines for naming the bubbles as you did for the 
data flows. Additionally , try to construct names with a 
singular action verb and singular object. If you find your- 
self caught using two verbs for one bubble, it may be time 
to repartition. 

After one iteration of the DFD process, a good 
practice is to set it aside for awhile before beginning the 
refinement process. The refinement process consists of 
examining each bubble and data flow line to determine if 
further decomposition is required. Information continuity 
is required on all refinements in that all incoming and 
outgoing data flows in a refinement must have appeared on 
the previous version. Figures 4.7 and 4.8 show a initial 
decomposition of a process bubble an d a subsequent refine- 
ment. The iterative process continues until the analyst 
feels that all bubbles and data flows have been completely 
developed or until further decomposition would not be of any 
practical use in his opinion. Clearly, experience will best 
teach the analyst when the bottom level is reached. 
Furthermore, final versions of DFD's from this stage of the 
design methodology may be required to be modified during the 
next phases of the methodology. 
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Examples cf DFD developmear for the HSCLCS are 
contained in Appendix A. 

c. Using the DFD 

The initial use of the DFD is to converx this 
product into a Function Hierarchy via the transform/ 
transaction analysis technique described in the next 
section. The Program Manager will use the DFD's to famil- 
iarize himself with the basic data flow cf the design cf the 
system graphically without having to trace the flow of data 
through a lengthy algorithm, the Broad Specifications, or 
the final design. This initial graphic understanding of the 
system to be managed will also allow the Program Manager to 
more easily understand the final design itself and to be 
able to quickly conceptualize the flow of information 
refered to in the design decisions documentation. 

The data flow analysis, completed in the form of 
data flow diagrams, will lay the corner stone for the devel- 
opment of the design. This process must be done carefully 
to insure than the foundations for modularity and implicit 
infer maticn hiding are established from the beginning of the 
system development process. 

2 • Tra nsf 0 rm/Tra nsa cti cn A naly si s 
a. Definitions 

Transform/transaction analysis is an algorithmic 
technique for developing a Hierarchy of Functions which is 
dependent only on the structure cf the input product, the 
Data Flow Diagrams. As the method name implies, there are 
only two high-level structural forms indigenous to data flow 
diagrams: transform flow and transaction flow. The method 

supposes that certain fundamental characteristics exist in 
all software systems: data must be input, manipulated, and 
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Figure 4.8 HSCLCS Display Engagemem: DFD Refineaenz One. 
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output. Thsse char acrer ist ics are broad enough in nature to 
nake the technique widely applicable to many types of soft- 
ware development. Specifically, -he merhod is highly ccmpa- 
table with the development of real-time systems making in 
ideal for cur purposes. The reader desiring furnher discus- 
sion of the technique should consult Pressman [Ref. 5]. 

Transform flow, our fundamennal system model for 
all dana flow, envisions the sysnem as inputting and output- 
ting dare in an ’’external world" form and processing (trans- 
forming) of information in an internal form. Transform flow 
is necessary to accommodate both the user who must input and 
interpret data in the external form and the computer which 
must process data in the internal form. Simply stated, if 
the flow of information can be viewed over time as; (1) an 
afferent flow from the external representation of the inputs 
to the internal representation; (2) a process flow where the 
internally represented data is manipulated to produce the 
desired results; and (3) an efferent flow from the internal 
representation to some appropriate external display for the 
information then transform flow is present. Figure 4.9 
illustrates the transform flow of information. Transform 
flow, as a basic model for all software development, charac- 
terizes systems very simply. They input data, change it to 
an internal form, process it, change it to a suitable output 
structure, and output it. 

To solidify the above discussion, we must define 

afferent and efferent flow which is the key to the charac- 

terization of transfer® flow. Afferent flow is information 
flow along paths which cause the gradual transformation of 

data from an external format to an internal format. The 

transformation cein be viewed as a tunneling of the informa- 
tion through external/in tsrnal interface translators toward 
a central processing pcint, a transform center. Efferent 
flow is the flow of information outward from the transform 
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Figure 4.9 Txansform Flow. 

center through internal/external interface translators to 
the devices which will display the resales of the processing 
to the system user. 

Transaction flow is characterized by a process, 
called a transaction center, which takas an external impetus 
and causes the data flew to be directed down one of several 
paths emanating from the transaction center. The path taken 
is determined by the value of the input. Figure 4. 10 shows 

the generic form of a transaction flow. An easy visualiza- 

tion of transaction flow is to compare it with the standard 
case statement. The case statement structure corresponds to 
the transaction canter, the case variable value is equiva- 
lent to the external impetus (input) , and the subprccess 
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Figure 4.10 Transaction Flow. 



called when executing the case statement corresponds to the 
action path taken in the Data Flow Diagram. 

t. Procedures: k Case Study 



To present the t ransf orm/transactio n analysis 
technique, a case study of the asCLCS Display Engagement 
Module will be used. The Data Flow Diagram pertinent *c the 
case study is shown in Figure 4.8. A general rule applicable 
to this analysis is that the entire refinement process of 
the Data Flow Diagrams must be ccmplerad before commencing 
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the procedure. Otherwise, the proper st 
function Hierarchy cannot be assured, 
detailed below provides a template for a gene 
some relatively simple developments, all of 
not be needed, e.g. secondary flow analysis, 
fore be oaiitted. 



ructure of the 
The procedure 
ric system. In 
these steps may 
and can there- 



(1) Flow C harac teri s ties. The first step of the 
procedure is to determine the characteristic flow of the 
data. It is possible for both types of flow to exist on a 
single diagram; this is the case for our rxampie. Under 
these circumstances the dominant flow patsrn must be deter- 
mined. In the case study, the transaction flow about the 
bubble labeled "Display Engagement Controller" appears to be 
dominant. 



(2) Mar }<inq the Dia gra m . Next the Data Flow 
Diagram is annotated to shew the various flew boundaries. 
Because the transaction flow is dominant, we wrli apply the 
rules for raarhing the transaction flow first and look for 
the af f ar ent/ef f erent boundaries to mark the transform flow 
second. The rules for transaction analysis begin with 
finding and isolating the transc.ction center. As the defi- 
nition states, the transaction center is that procedural 
bubble which contains multiple radially emanating data 
paths. Figure 4.11 shows the isolation of -^he transaction 
center for the case study. This identification of the major 
flow will ultimately develop the upper level modules on the 
Function Hierarchy. To provide details for a good Hierarchy 
Chart, further refinement of the flow characteristics must 
be performed. Since all of the secondary flow in the case 
study is transform in nature, the next step is to locate the 
transform centers. They are easily found by observing the 
afferent flow into selected procedural bubbles and the effe- 
rent flow cut of others. In the case study, the secondary 
flow on the left side of the transaction center is detailed 
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Figure 4.11 Isolation of the Transaction Canter, 



6 1 




I 



while cn the right side it is trivial (see Figure 4.12). 
The right side is trivial because the flow boundaries are in 
lowest terms: a single datum afferent flow; a single 

processing bubble; and a single datum efferent flow. Thus, 
one would expect the modular breakdown on the input side of 
the hierarchy to be somewhat more detailed than that on the 
controller side. Later this will be shown to be the case. 

(3) Hier archy cf the Do minan t F low . Once the 
Data Flow Diagram is appropriately marked, the first cut 
hierarchy for the dominant flow is generated. The fact that 
flow is the key to generating the hierarchy supports the 
supposition that the structure built during the data flow 
analysis will be maintained. Both types of flow have 
strictly mechanical means to arrive at the first cut hier- 
archy. This is because of the way data flow diagrams are 
partitioned when marked. 

When the dominant flow is transform in 
nature then the first-level factoring produces a two level 
hierarchy. The upper level is a control module with a 
generic name chosen to illustrate the global function of the 
procedure. The second level contains three generic control 
modules with the following functions; one coordinates the 
afferent information, the second controls the processing, 
and the third coordinates the efferent information. The 
process bubbles controlled by these three modules are 
captured by the afferen t/processing/ef ferent boundaries 
marked on the Data Flew Diagrams. 

Should the dominant flow be transaction in 
nature, the first-level factoring produces a three level 
hierarchy. The upper level performs the same function as 
its counterpart used in transform flow. The middle level 
consists of two controllers: one for controlling modules 

which handle the input flow to the transaction center and 
one for controlling modules which handle the individual 
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Figure 4,13 DoBinant Plow First Cut Hierarchy- 

paths emanating from the transaction center. The bottom 
level consists of a group of modules each corresponding to a 
single data path out from the transaction center. Figure 
4.13 shows the first cut hierarchy for the dominant trans- 
action flow of the case study. 

(^) Hie rarchy of Secondly Flow s. The first 
cuts of the secondary flows, which are handled next, are 
performed in exactly the same manner as the dominant flow. 
The only difference is that the top level module, the 
controller, for secondary flow must be identified as seme 
module on the first cut dominant flow hierarchy. Because 
the secondary flows are marked in relation to the markings 
of the dciinant flow 'and cannot cross already existing flow 
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Figure 4,14 Secondary Flow First Cut Hierarchy, 

boundaries, secondary flows are always encapsulated within 
either the dominant or another secondary flow. Therefore 
the tcp level ccntrcller of a secondary flow must map into 
some lower level module of the dominant flow's (or a 

controlling secondary flow's) first cut hierarchy. Finding 
this lower level module is easy; it is the one which 
performs the labeled function on the Data Flow Diagram, 
Figure 4.14 shows the first cut hierarchy for the secondary 
flo w . 

(5) Second -Leve 1 Fact ori ng. Secondary factoring 
is concerned with developing the lower level modules in the 
hierarchy. It is basically a mechanical process of locating 
modules which perform the same functions as their data flow 
diagram bubble counterparts. The bubbles contained within 
the flow bcundaries created by marking nhs diagrams are 
required to be mapped into modules subservient to the 
contrcller for that particular subflow (i.e. the afferent, 
processing or efferent transform flows or the input or 
dispatcher rransacticn flows). 
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It is not mandatory zo have a ons-to-one 
mapping between bubbles and modules although the degree of 
mechanicalness of the process is dependent upon this. This 
step should be performed as mechanically as practical to 
preclude loss of information due to premature refinement. 
However, mapping strictly by mechanics withour regard for 
obvious simplifications fails to decrease the complexity of 
further factoring. Practical considerations dictate the 
outcome of the second-level factoring. Figure 4. 15 shows 
the second- level factoring for the case s-udy. It was done 
in a mechanical fashion so that the refinement techniques 
discussed below could be more adequately shown. 

(6) Refi nement H euri s tic s . The first cut struc- 
ture of the hierarchy diagram has many rough edges. The 
smoothing process is not well defined; it applies a series 
cf heuristics to the Function Hierarchy to refine the system 
structure. These refinements are necessary to promore one 
software principles discussed throughout the thesis. The 
following heuristics, offered by Pressman [Ref. 5], meet our 
needs ; 

1. "Evaluate the preliminary software design to reduce 

coupling and improve cohesion." If a module encom- 
passes multiple functions, the software structure 
will suffer a loss of cohesion. Explosion of the 
mcdule into a set of single-function modules regains 
the cohesion. If a module has an unreasonably 

complex interface, coupling will increase. Implosion 
of the function into the parent module will simplify 
rhe interface. Note that implosion and explosion 

have opposite effects on coupling and cohesion. The 
optimal balance between coupling and cohesion is the 
goal and drives the module refinements. 

2. "Attempt to minimize structures with high fan-out; 
strive for fan-in as depth increases." An example of 
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a high fan-out structure is a tree. This type of 
structure does not attempt to absrract similar parts 
from modules and maice them su bprccedures to a multi- 
tude of higher level modules. It is therefore a 
wasteful structure. Fan-in at a low level generally 

indicates a well abstracted structure with singular 
purpose modules. 

3. "Evaluate module interfaces to reduce complexity and 
to improve consistency." The paramerers passed to a 
module must be simple and consisrenr with rha func- 
tion of the module. Orherwise low cohesion and 
confusion on the part cf the module user will result. 
If a complex interface is necessary to reasonably 
perform the desired task then all the modules in the 
immediare area should be reevaluated. 

4. "Strive for single -entry , single exit modules, 
avoiding pathological connections." This simply 
warns us to develop modules which are entered at the 
top and exizted at the bottom. Pathological connec- 
tions are branches into or out from the middle of a 
module. They must be religiously avoided. 

( 7 ) Refin ement P roce ss. The refinement heuris- 
tics listed above fall under the general category of module 
independence promoters. Seeking high cohesion and low 
coupling by the implcsion/e xplosion routine is necessary in 
varying degrees to gain this independence. The degree of 
necessity is dependent upon the level of refinement of the 
Data Flow Diagrams. As the DFD's capture more detail, the 
number of correct, efficient Function Hierarchies decreases 
because detail limits design options. Thus, as the set of 
DFD's approach tnaximum refinement the transf orm/transact ion 
analysis process approaches a fully mechanical algorithm. 
Eut because the level of refinement of the Data Flow 
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Diagrams is realistically (and desirably for complexity 
reduction reasons) rough, heuristics are needed to refine 
the Hierarchy Chart. As indicated, these heurisric proce- 
dures are not mechanical. They rely on common sense 
decisions by the user to transform the current structure to 
a form which simplifies the design. The final arbiter is 
human judgement. 

In the case study, several refinements can 
be made. Refer to Figures 4.15 and 4.16 throughout the 
narrative. First, to aid abstraction and control coupling 
all references to data in databases will be through a gener- 
alized data interface, an abstract database management 
system (DBMS). Thus, the two database manager modules have 
been replaced on the final hierarchy by a generic ccntrcller 
for all calls to databases. It is beyond the scope of this 
discussion to refine the DBMS module. Next, the “Accept 
Display Engagement Command" module, which performs no 
processing, was for simplicity reasons imploded into the 
“Accept Inputs'* module. Third, the processing of the 
“Process Inputs" module, which is done by the “Accept 
Inputs" module, and the processing of the “Output Engagement 
Data" module, which consists of only a parameter pass, are 
not necessary to control cohesion. This type of redundancy 
is common to secondary flow analysis. Consequently, they 
were imploded into the “Input Controller" module. Next, 
because the function of the “Input Controller" and the 
“Accept Inputs" modules are identical, the structure can be 
simplified to a single module to reduce coupling with no 
loss of cohesion. Note that the final name chosen for this 
second level module was "Process Inputs" rather than “Input 
Controller" or "Accept Inputs". This is because the name 
"Process Inputs" is the most descriptive of these three 
candidate names for the module. The final modification to 
the design, that of abstracting similar data from the two 
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.16 Hierarchy of Functions: Final Hefineaent. 
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scaling modules, attempts to *'fan-in” the structure. It is 
shown as a dotted procedure on Figure 4.16 to show that 
factoring is possible but not assured. 



3 • Kc d ular Deve lcpmen t 



Hodular develcpment as a formalized procedure is a 
technique for transforming the properties of the Hierarchy 
Chart structure into Module Descriptions. All of the data 
required to define the modules in very general terms is 
contained in the structure cf the Function Hierarchy. The 
transformation, while seemingly subtle in nature, is a very 
important step in the methodology. It provides an elegant 
way of changing the system specifications from their totally 
graphic fcrm into a short narrative form. This transition 
is a necessary first step toward using an SDL, an ABA S CL in 
our case, to further design the system. 

The components of a Module Description capture the 
necessary details of modules commensurate with their high- 
level position in the design refinement process. While the 
actual format of the Module Descriptions is not critical, 
the contents contained within them is. The components 
provide a complete description of the module for this stage 
cf the design. The definitions of each of the Module 

Description parts are listed below: 

1. Module Name. This name must be the same as the one 

on the corresponding module of the Function 

Hierarchy. 

2. Module Function. This narrative provides the purpose 
of the module in broad terms. It should reveal a 
singular purpose in order to meet the criteria of a 
module. 

3. Supervisory Modules. These are the modules that call 
this module. It is the interface with the supervi- 
sory modules which is explained below. 
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4. Module Interface (Parameters). Here the ADA 

SDI-styled parameters are listed and further 
explained in a shcrr narrative. The narrative 
reveals the basic structure for ' the data type of the 
parameters. The interface is a bridge between this 
module and all of its supervisory modules. 

5. Subordinate Modules. These are the modules called 
within the body of this module. Their interface 
definitions are handled by the subordinate module's 
interface . 

6. Design Decision Encapsulation. This is the singular 

decision which the module hides wirhin its body. It 
must be a singular decision to meet Parnas's criteria 
for a module. As the module is further developed, 
additional lower level decisions will usually be 

necessary. To maintain the Parnas singularity 

requirement, these decisions must also be encap- 
sualted in their own procedural structure. Thus, the 
Hierarchy Chart is a dynamic product being continu- 
ally refined as design questions arise and decisions 
are made to accommodate them. 

Figure 4.17 shows a recommended style for module 
descr ip-ions. The example is one of the modules developed 
in the case study, T HREAT_ANALYS IS_DISPLAY . Viewing Module 
Descriptions as the first step of the design in the SDL and 
therefore the first products of a step-wise refinement 
process for the system design, we present the descriptions 

in ADA SDL comment form. Because the Module Descriptions 

contain the necessary details to fully define the modules, 
they can be used as the user interface in the ADA SDL 
design. 

The modules should be developed independently by 
first producing the Module Descriptions in separate files 
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^:4c:fc:4c**4(^i^:4e*:4e * ♦ :^c * :^i 3^ :^t # ♦ :?c :«c:4c 4e * ^4e4e * * :4c* * 3^* * *:4c ^ **:$t**:0c*34f 

.: 4 e********** ^*3^ * * * ***:9e** ** * ** : 4 c * * : 4 c* :4c* * *:4c * :4c* **** ****** ** 



• ** ** 

-** ** 

-*♦ Module: THREAT ANALYSIS DISPLAY ** 

-♦♦ ~ *♦ 

-** Module Function; ** 

-** To query the database management sys- ** 

-** tem for the data required to display *♦ 

-** the threat data on the HSCLCS console ** 

• * * ** 

-** Supervisory Modules: ** 

PECCESS INPOTS ** 

- ♦ ♦ 

Module Interface (Parameters) ; ** 

-♦* - Threat: out Threat Type =*♦ 

-*♦ (This is a buffer for holding the ** 

-** current threat data suitably for- 

-** matted so that the task THREAT in *♦ 

the package DISPLAY can put the ** 

-** data to the CRT.) ** 

-** ** 

-** Subordinate Modules: =♦♦ 

DATABASE MANAGEMENT SYSTEM ** 

- * * * * 

-♦* Design Decision Encapsulated: 

-** The interface with the supervisory ** 

-** module will contain the structures in ** 

-** CRT grid coordinates compa table with =*"♦ 

-** the CRT used. This moduxe is there- ' ** 

-♦* fore an abstract interface between the 

-** data positions contained in the data- ** 

-*♦ bases and the actual CRT positions. *♦ 

- * * ** 



• *:4e* ******************** ********************** ****** ** 
-.**♦♦♦ :4c* ******* ******************************* ******** 
«**:4(:4e* ****************** ********************** ******** 

I J 
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^ ADA Design 

The transition to ADA design function complenes the 
system design. Using the method for segregating and docu- 
menting the Module Descriptions explained in the last 
section, the transition builds the narrative structure into 
an ADA-ccmpilable System Design Language "program”. It 
incorporates the stepwise refinement approach of detail 
abstraction throughout the process. The steps involved in 
this function are simple to comprehend and follow for those 
moderately versed in the stepwise refinement technique. 

Stepwise refinement is a well-known concept in the 
software engineering community. It is not universally 
accepted, however, as the all-encompassing detail abstrac- 
tion methodology. Because it is very useful at this point 
in our methodology, we have endorsed it. In a nutshell, 
stepwise refinement is a decomposition procedure which 
refines a previous, higher-level view of a module. It is 
different from a similar technique, top-down design, because 
unlike the top-down method, stepwise refinement is limited 
to developing only structured constructs within modules. 

Before preceding with the refinement process, the 
Data Flow Diagrams, Module Hierarchy, and Module 
Descriptions must be reviewed to identify potential modules 
for packaging and to look at the concurrency profile (best 
shown by the DFD*s) of the system. The packaging criteria 
consists of four general categories of applications for 
packages «ach with multiple subcategories. The broad appli- 
cations are: named collections of declarations; groups of 

related program units; abstract data types; and abstract 
state machines. Bocch [Hef. 8] discusses these criteria in 
detail. Applying these criteria to the case study, notice 
that the three display modules along with the 
"PROCESS_INPDTS" module in Figure 4.16 would be candidates 
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for ADA packaging. This is bacausa by packaging chase 

modules the reguired inputs can be hidden from the 
”DISPLAY_ENGAGEMENT" module thus realizing both a grouping 
of related program units and an abstract state machine. The 
criteria fcr ADA tasks alsc serve four applications areas: 
concurrent actions; routing messages; managing shared 

resources; and interrupt handling. Again Booch [Hef. 8] 
explains these applications in detail. Returning zo the 
case study, these three display modules perform functions 
independently of each other as shovrn on Figure 4.3, the DFD, 
(i.e. they do net operate on the same input parameters) and 
conseguently are candidates for concurrency control using 
the ADA task mechanism. 

The procedures of the stepwise refinement are not 
particularly rigid. As previously stated, the main idea is 
to decompose modules into structured constructs. The 
following steps form our methodology for completing the 
design. 

1. Write the procedure, package, function, task, etc. 
specification including all of its parameters. 

2. Write the body name of the procedure, package, func- 
tion, task, etc. with its parameters, a shorn narra- 
nive of the basic flow, and the appropriate end 
statement. 

3. Replace the narrative of the body by the high level 
constructs of the algorithm. 

4. Continue refining the algorithm by adding detail 
until the desired purpose is clear. Give no more 
detail than necessary to meet the above criteria. 

5. If during this process the need for design decisions 
arises, defer the decision by creating a subordinate 
module specifying only its interface. 

6. Recheck the interfaces for clarity, simplicity, and 
completeness . 
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Determine the design decision encapsulated in the 
module and check rhat it is entered in the appro- 
priate Module Description. 

Figure 4.18 shows the ''THREAT_ANALYSIS_DISPLAY’' 



task THREAT ANALYSIS DISPLAY; 
with LATABA3E MANAGEMENT SYSTEM; 
task bcdy THR'EAT ANALYST'S DISPLAY is 
type THR DBMS Is 
record 



these types are not 
pertinent to the case 
study and therefore 
not developed 



THR DBMS 



SHIP NAME: 

SHIP" CL ASS; 

WEAPONS : 

ECM EQUIPMENT: 

ENGIGEMENT_PL AN: 
end record; 

THREAT ; THREAT TYPE: 

RECORD FROM THREAT DB 
END FILE : ■BOOLEAN! 
begin" 

END FILE := false; 
while (not END FILE) loop 

THREAT DB MGR (REC0RD_FR0M THREAT DB, END_FILE) ; 

- deveIop"th€ CRT coordinates for"this display 

- consistent with the known coordinates of the 

- actual threat, out the names and coordinates 

- in the buffer, THREAT, 
end loop; 

end THEEAl' ANALYSIS DISPLAY; 



Figure 4. 18 Sample Module Design in ADA SDL. 



design which completes the case study for this module. 
Stepwise refinement was used both to develop the specifica- 
tions cf the task and the flow in the task body. Because 
all of tte specifications were accurate and the interface 
well-defined, this step in the methodology was easily 
performed . 

5 . Specification Refin ement 

Cne of the primary goals of the methodology is to 
produce better specificati cns and at this point in the 
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process the existing specifications are updated by incorpo- 
rating the documented design decisions. Also if certain 
decisions were deferred until now such as exception 
handling# it is the time to include them in the specifica- 
tions. On the first iteration of the methodology the input 
for the update process would be the Broad Specifications. 

We are assuming that the Broad Specifications are 
well structured and in accordance with current directives. 
However, at each review point of the specifications they 
should be screened fcr ambiguity, confusing description, 
overspecif ication, orthogonality, and completeness. The 
preceding processes in the methodology will iteratively 
ensure cc mpleteness , but the other undesireable attributes 
must be found editorially. We will not belabor the reader 
with definitions of the attributes but they can be found in 
[Ref. 73. 

A sample set of software specifications for the 
HSCLCS is given in Appendix F. These specifications were 
the product of a first iteration of the methodology for the 
system and, if approved by a Program Manager, would be the 
final refined software specifications. 

Although this section of the methodology appears 
short in comparison to the long algorithms of the other 
methodology components, the review of the specifications is 
extremely important and should be given an equal if not 
greater segment of the methodology time. These specifica- 
tions will reflect the principles incorporated into the 
ether methodology products only if this updating process is 
dons wizh care. 

C. HETHCDOICGI EVALDiTION 

In the first section of this chapter we listed and 
discussed the principles and goals chat the methodology was 
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designed to produce. In this section we will show how the 
products produced conform to the guidelines specified. 

To begin with, all of the products were created using 
concrete algorithms which were presented in a manner rhat a 
Program Manager could easily understand. Although the 
processes did include some heuristics, rhe thought process 
behind the heuristics was explained thoroughly. 

Each of the products exhibit logical design flow at all 
levels of development. The stepwise refinement methods in 
each phase cf the methodolcgy insured that in no way did a 
cart ever get in front of a horse. From data flow diagrams 
to design to specifications, system design decisions were 
deferred until the last possible moment in order to maintain 
the maximum decree cf flexiblility and to enforce abstrac- 
tion. This logical design coupled with the algorithmic 
methods along with emphasis on simplicity and structure in 
each of the products gives the methodology one of the 
primary gcals; understandability. 

The four basic principles (i.e. modularity, abstraction, 
independence, and hiding) that were enforced during the 
phases of system development all basically contribute to the 
modifiability and maintainability goals of the methodology. 
Modularity is the first of these principles and the entire 
system development process steered the analyst toward 
abstracting common characteristics of the system into 
modules. The abstraction process kept details of design at 
the lowest possible level. By hiding design decisions 
within modules, a design decision change can easily be 
incorporated into each of the products by simply changing 
one module (ideally). Furthermore since there exists a 
fairly simple mapping between products, a revision could be 
implemented easily across the board. Since independence was 
also one of the principles, strong cohesion and weak 
coupling of modules also enhances relatively effortless 
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system software modification. Clearly, the software devel- 
oped is easily modified and consequently highly 
maint ainatle. 

The iterative nature of the methodology ensures that the 
products will be reliable. The inherent design error 
checking of the process allows the designer to be confident 
that the design will meet all previously required specifica- 
tions and that the refined specifications produced by the 
methodolccy effectively encompass all design parameters. 

To simply state that the major principles used to 
develop the individual products insures that the desired 
characteristics are passed from phase to phase may nor be 
enough. Abstraction and completeness are natural byproducts 
of the data flow analysis methods of DeMarco, but do these 
traits proliferate through the Pressman and Booch module and 
design development processes? Does the modularity and inde- 
pendence gained from Pressman carry over to augment the 
hiding principle emphasized by Booch? The answers are 
emphatic affirmatives based on the iterative nature of the 
principle inclusion process of the methodology. 

Upon close examination it is easy to see that the prin- 
ciple inclusion process is additive in nature. Abstraction 
and completeness are qualities enforced in the derivation of 
the Data Flow Diagrams. Since these characteristics are 
imbedded in the DFD's, which form the basis tor the Pressman 
transaction analysis phase, they are necessarily a charac- 
teristic of that phase also. Additionally, modularity and 
independence are emphasized on top of the abstracted, 
complete foundation. Similarly, the characteristics brought 
forward from Pressman to the design development of Booch are 
added to information hiding which is stressed in that phase. 
In this way we are guaranteed that the ultimate products 
possess the desired traits. Iterative refinement of the 
processes then solidifies the placement of the principles. 
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An evaluation of the methodology would not be complete 
withouT seme comment on ADA as the system design language, 
however, no in-depth analysis of ADA will be given because 
it is outside the scope of this rhesis. Besides being the 
DOD language of the future, ADA, with its package and task 
mechanisms, is especially suited zo enforce the information 
hiding principle that is the major emphasis of the Eooch 
phase of the methodology. Without such a language, the 

implementation of this principle would be tedious if not 
practically impossible. In short, ADA is not jusr used by 
the methodology; without it the methodology would non be 
complete. 

Even though we have shown that this methodology will be 
an effective tool for the Program Manager, it must be 
stressed that if all of the guidelines and principles are 
not adhered to rigidly thoughout each phase of the process 
then the products may not reflect the qualities specified by 
the goals. To use simply modularity without hiding in mind 
could result in software that is not easily modifiable while 
not applying all of the rules of abstraction could yield a 
very inefficient design. The major distinguishing trait of 
this methodology from others such as FSL/PSA and SADT is 
that the various software engineering techniques of Booch, 
De Marco, Pressman, and Parras have been blended to form a 
process that generates products that can begin to cut the 
cost of software maintenance and development. To employ the 
process you must be well schooled in the basic principles. 

It is apparent that the goals of the methodology have 
teen achieved from the previous discussion, but only through 
implementation of the process can it be evaluated. The only 
readily obvious improvement upon the methodology would be to 
automate the process which is well within the realm of 
possibility due to the algorithmic nature of the method- 
ology. The methodology was used to produce the design 
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products for the HSCLCS were are included in the appendices. 
For this size project the methodology appeared excellent. 
However, the i nple lent ors found that increased experience 
with the phases produced results which more closely adhered 



to the goals and principles, 
pudding. 



Further proof will be in the 
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CONCLOSIONS 



The goal of this thesis was to develop a system to make 
the Program Manager's task of monitoring software develop- 
ment of embedded weapons systems lass complex by providing 
him with comprehensible, easy to use management tools. In 
the previous chapter we have outlined and evaluated a meth- 
odology which produces these management tools, and in the 
appendices are samples of the products of the methodology. 
The methodology was simple to implement and produced good, 
complete system software specifications that were under- 
standable and well documented. An explanation of the 
Program Manager's procedure in utilizing these software 
development tools remains. 

The Program Manager will receive broad software specifi- 
cations on which he will conduct a first cut evaluation 
prior to giving them to a Contract Support Service (CSS) for 
generation of refined specifications using the methodology 
of this thesis. After a specification refinement, the 
Program Manager reviews the methodology products and feeds 
the Refined Specifications back to the CSS if necessary for 
another iteration of the process of refinement. This process 
continues until optimal specifications are achieved in the 
opinion of the Program Manager and his staff. A close 
working relationship between CSS and Program Manager can 
accellerate the process ccnsiderabl y. Specifications of 
high quality is the most visible product of the process 
external to the Program Manager's office, but the other 
products are equally important to che management of a soft- 
ware system. 

The Data Flow Fiagrams, Module Descriptions, and design 
with documentation are of high value. The Data Flow 
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Diagrams provide an easy-tc-read graphic representation of 
the system. The aodule Descriptions and the final ADA 
Design produced give further simple, understandable docu- 
ments that a Program Manager and especially his successor 
(relief) can use to grasp the details of the software. The 
Documented Design Decisions are even more important to the 
pass-down evolution that so often interrupts the continuity 
of a system's development. A new Program Manager can not 
only see the design with relative ease, but he now has a 
history of how and why decisions were made that led to the 
design. Corporate knowledge which has historically been the 
most frequent casualty of the turnover process can therefore 
be a survivor. The increased insight into the design of the 
proposed system also puts the Program Manager into a batter 
position to evaluate the ultimate system cont racror ' s design 
proposals . 

Another byproduct of betzer specifications is the poten- 
tial for overall system development coszs to be lowered. By 
refining the specifications "up front", there is a reduced 
probability that the contractor will discover omitted items 
in the specifications that require costly change orders to 
integrate the items into the system. Since change orders 
allow contractors to adjust the cost of a system above the 
original bid, reducing the number of changes minimizes 
overall costs. Further in the costs lifecycle area is the 
capital spent on the maintenance of a system once it is 
implemented. Modification of software generated by this 
methodology is relatively inexpensive as discussed in the 
previous chapter. In most cases changes in requirements 
would not require a complete system redesign but only rede- 
sign of the module affected. Maintainance costs would than 
be obviously lowered. 

The most intangible benefit gained from the methodology 
is the economy of effort gained within the Program Manager's 
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cffic€. The algorithmic style cf the methodology and the 
uniformity cf the products provide guidelines for the soft- 
ware development. The lack cf an adequate institutionalized 
procedure for software development organization in the past 
has caused effort tc be wasted performing non -produce ive 
tasks. Therefore, the increased efficiency due ro standard 
development procedures can be substantial. 

Software development, as mentioned before, is but a mere 
fraction cf the total effort needed to realize an embedded 
system in the fleet. However, the escalating cost of soft- 
ware makes it contribute an inordinate amount to the total 
svstem costs including system maintenance. It is therefore 
imperative that the best software engineering techniques be 
used to reduce the exponential growth of development and 
maintenance expense and to ensure the Program Manager's task 
has minimum complexity. The methodology promulgated by this 
thesis is a major step in developing standardized management 
procedures for software development that will reduce costs 
and provide more maintainable weapons systems to the fleet. 
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APPENDIX A 



HSCLCS DATA FLOW DIAGRAMS 

This appendix contains the HSCLCS Data Flow 
from [Ref. 1 ]. This set of diagrams is by no means 
and is crovided as a sample methodology product, 
caveat applies to each of the appendices. 



Diagrams 
complete 
The same 
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Figure A.1 S-aurcs/Sink Diagram. 
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Figure 1.2 



System Oterviaw DFD. 
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Figure A. 3 Ccaplete Manual Process Data Flow Diagram. 
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Figure 1.4 Update Track Data Base DFD. 
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Figure a. 5 Coeplete Convert Environmaatal Data DFD. 
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Figure a. 6 



Decode Output DFD. 
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Figure A. 7 



Plan Engagement DFD. 
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HSCLCS HIERARCHY CHARTS 



These are the HSCICS Hierarchy charrs froa [Ref. 2]. 
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Figure B. 1 



First Cut Transform Analysis. 
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Figure B,2 Befiaenent of Transform Analysis, 



95 



KOCt:>s iripui 



r 



1 




I I 



Figure B.3 



Process luput- 
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Figare E.4 



Process Engagsmenr, 
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Figure B.5 



Process Display. 
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Figure 3.6 Program Design structure. 
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Figure B.7 



Transition S 



truer are 



of Figure B.6. 
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Jigure B.8 action Path Structure of Track Data Base Manager. 
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Figure 3*9 action Path of Environmental Data Base Manager. 
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Figure B. 10 



Action Path of 



Display Manager. 
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Figure B. 1 1 



Action Path 



of Engagement 



Hanager. 
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3.12 Action Path of Track Data Base Sgr, vfith Heuris 
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APPENDIX C 

HSCLCS BODOLB DESCRIPTIONS 



This appendix contain descriptions of the thirty one 
modules of the HSCLCS from [Ref. 1 ]. 



1 - 0 
2 - 1 

3 - 1.1 

4 - 1.2 



8 - 2 . 1.1 
9 - 2.1.2 
10 - 2 . 1 . 2.1 
11 - 2 . 1 . 2. 2 

12- 2.1.3 

13- 3.1 

14- 3.1.2 

15- 3.2 

16- 3.2.1 

17- 3.2.2 

18- 3.2. 2.1 

19 _ " 2 

20- 3.2.*3.1 

21- 4 

22- 4.1 

23- 4.2 

24- 4.3 

25- 4.4 

26- 4.4.1 

27- 4.4.2 

28- 4.4. 2.1 

29- 4.4.3 

30- 4.5 

31- 4.6 



C o nt r o 1 
Process Input 

Ship Parameter Data Base Manager 

Environmental Data Base Manager 

Threat Data Base Manager 

Convert Coordinates 

Type Track 

Delete Track 

Update Track 

Course and Speed Update 

Bearing, Range, and Position Update 

Ad d Tit sc)c 

Launcher and Missile Assignment 
Launcher and Missile Status 
Plan Engagement 

Plan Engagement Data Base Manager 
Engagement Data 
X li Q 

Probability of Acquisition 
Uncertainty Ellipse 
D isplay 
Menu Display 

Launcher and Missile Status Display 
Environmental Display 
Engagement Display 
Threat Display 

Automatic Engagement Display 
Graohics Display 
Manual Engagement Display 
Ship Parameter Display 
Track Display 
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:0c :0t ](e ^ 3}c :0e :Of3«e:0c:0s3jc:0c:0s:0e*:0s:4c:0c:0£*:0c:4£:0j:0c:0::flc:0c:0c4c3fr*:0s:<c2ic 

1. Module Name: CONTEOL, NOMEIR 0 

2. Module function: This module calls all other modules 

and determines the program flow. 

3. Supervisory modules: None 

4. Module inter face (paramet ers) : 

5. Subordinate Modules: Process Input 

Lau ncher-Mrss ile Assignment 
Plan Engagement 
Dis play 

6. Design decision encapsulated: 

:0c :0c :0e :0s :0c ♦♦ :0c :0c :0:0c :0c :0c:je :0c ♦ :0c :je :0s :0s :flt :0:0s :0c :0c :0c :0c ^ ^c :0s :0c :0c 30c :0c :0c :0c :0c :0c :0c :0s :0s :0: :0c :0c :0c :0c :0c :0s :0c :0c :0c :0c :0c :0c :0c :0c 

1. Module Name: PROCESS INPUT, NUMBER 1 

2. Module function: Selects subordinate module to update 

corresponding data bases. 

3. Supervisory modules: Control 

4. Module inter face ( para met ers) : 

5. Subordinate Modules: Shio parameter Data Base Manager 

Environmental Data Base Manager 
Convert Coordinates 
Threat Data base Manager 

6. Design decision encapsulated: 

44 V* ****************************** 

1. Module Name: SHIP PARAMETER DATA BASE MANAGER, 

NUMBER 1 . 1 

2. Module f unction : U pdate the Ship Parameter Data Base 

by either manual or automated means. 

3. Supervisory modules: Process Input 

4. Module inter face (paramet ers) : 

5. Subordinate Modules: None 

6. Desian decision encapsulated: 
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1. Module Name: ENVI ECNMENT AL DATA BASE MANAGER, NUMBER 1.2 

2. Module function: Update the Environmental Data Base bv 

either manual or automated means. 

3. Supervisory modules: Process Input 

4. Module inter face (paramet ers) : 

5. Subordinate Modules: None 

6. Desiqn decision encapsulated: 

:#c :^s :^c:^c :Jc :^c :^e:jc ♦ sje :$e :«c :4c 3$: :0c :«( :4c4e :4c 4c :0c:4e :4c :4c ^ ifc 4c :Jc:4e 

1. Module Name: THREAT DATA EASE MANAGER, NUMBER 1.3 

2. Module funct ion: Update the Threat Data Base bv either 

manual means or through use of a 
standard chip that can be periodically 
updated and sent to all ships with 
HARPOON capability. 

3. supervisory modules: Process Input 

4. Module inter face ( para meters) : 

5. Subordinate Modules: None 

6. Design decision encapsulated: 

1. Module Name: CONVERT COORDINATES, NUMBER 2 

2. Module funotion:To convert all the inputs to update track 

data to common coordinates. The inputs 
can be manual, from own ship's tracking 
eguipment, or from an NTDS link from 
other platforms. 

3. Supervisory modules: Process Input 

4. Module inter face (paramet ers) : 

5. Subordinate Modules: Type Track 

6. Design decision encapsulated: 
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* :^:^:^:4e * :^c :^c :^c :i^i^ :|e:«c:^:Ct:^c:^:«c^ 



1 . 

2. 



iacdul€ Name; 



TYPE TRACK, NUMBER 2. 1 



3. 

4. 

5. 



Module function :Type Track determines if the track is 

be deleted from the data base, added 
the data base, or some parameters of 
existing track are to be altered. The 
actions are oerformed by selecting zh 
appropriate subordinate module. 

Supervisory modules; Convert Coordinates 

Module interface (parameters) : 

Subordinate Modules: Delete Track 

Update Track 
Add track 



6. Design decision encapsulated: 



:4c :^e :9c:4c :4c :}c :4c:4c :4c :4c :4c34c:9e :0c:4c : 4 c :4c :4c :4e :4c :4c :4c :4c :4c :4c :4c :4c :4c :4c :4c ^4c :4c ^4c ♦ :4c:4c ♦ ♦ :4c :4c :4c* ♦♦ ** 



1 . Module Name; DELETE TRACK, NUMBER 2.1.1 

2. Module function: To eliminate tracks from the data base 

that the operanor determines are no 
longer useful. 

3. Supervisory modules: Type Track 

4. Module inter face (para meters) : 

5. Subordinate Modules: Track Data Base Manager 

6. Design decision encapsulated: 



♦ 4c:4c4: *<c 



1. Module Name: UPDATE TRACK, NUMBER 2.1.2 

2. Module function :Tc update the information contained in 

the Track Dana Base. 

3. Supervisory modules: Type Track 

4. Module inter face ( para me ters) : 

5. Subordinate Modules: Course and Speed 

Bearing and range 

6. Design decision encapsulated; 
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4444444 44 4 44 444 44 44 4 44 4 44 4444 4 4 444 4 44 

1. Modul-= Nama: CODHSE AND SPEED UPDATE, NUMBER 2. 1.2.1 

2. Module function: Ic update the course and speed infor- 

tion on each track contained in the 
Track Data Base. 

3. Supervisory modules: Update Track 

4. Module inter face ( para meters) : 

5. Subordinate Modules; Track Data Base Manager 

6. Design decision encapsulated; 

1. Module Name: B EARING .RA NGE AND POSITION UPDATE, 

NUMBER 2, 1 , 2. 2 

2. Module function; Tc upgate the bf a ring/3;angs and position 

(Latnit ude/Longinuda) information on 
each track in the Track Data Base. 

3. Supervisory modules; Update Track 

4. Module interface (parameters) : 

5. Subordinate Modules; Track Data Base Manager 

6. Design decision encapsulated; 

4 444 444444 4 444444444444 44444444 

1. Module Name: ADD TRACK, NUMBER 2.1.3 

2. Module function: Tc allow new tracks to be put into the 

Track Data Base. 

3. Supervisory modules: Type Track 

4. Module inter face (paramet ers) : 

5. Subordinate Modules: Track Data Base Manager 

6. Desian decision encapsulated; 
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1. Module Name; LAUNCHER AND MISSILE ASSIGNMENT, 3.1 

2. Module function: Allow the operator to bypass the 

engagement planning automatic 
selection or missile cell 
and simply select and launch the 
missile manually. 

3. Supervisory modules: Control 

4. Module interface (parameters) : 

5. Subordinate Modules; Launcher and Missile Status 

6. Design decision encapsulated: 






1. Module Name: LAUNCHER AND MISSILE STATUS, NUMBER 3.1.2 

2. Module function: Tc provide current information cn wha 

launchers (port - starboard) are read 
tc fire and which and what types 
missiles are ready to fire. 

3. Supervisory modules: Launcher Missile Assignment 

Engagement Data 

4. Module interface (parameters) ; 

5. Subordinate Modules; None 

6. Design decision encapsulated: 



:4c :4c :4c :4c :4c 34c :4c :4( :4c :4c :4c :4c :4c :4c :4c :4c :4c :4c :4c :4c :4c :4c :4c :4c :4c* :4c :4c «:4c :4c« ♦♦♦♦♦♦♦ :4c ♦ :4c ♦♦♦ :4c ******** 



1. Module Name: PLAN ENGAGEMENT, NUMBER 3.2 

2. Module function: To determine the optimum engagment plan 

for a given target. 

3. Supervisory modules: Control 

4. Module inter face ( para meters) : 

5. Subordinate Modules: Plan Engagement Data Base Manager 

Engagement Data 
Probability of Acquisition 

6. Design decision encapsulated: 
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1. Module Ncma: PLAK ENGAGEMENT DATA BASE MANAGER, 

NUMBER 3.2.1 

2. Module function: To update the Engagement Plan Data Base. 

3. Supervisory modules: Plan Engagement 

4. Module inter face (paramet ers) : 

5. Subordinate Modules: None 

6. Design decision encapsulated: 

:flc * :flc*5}c*:^:4c:«c:^c:flc :^c :^c:#c :flc :«c ♦ :^t :flc :^c :#c :«c * :^e :^c :flc :^c :^c :^c :(c :Jc :^c :^c :^c 4: :Jc :#c :flc :^c 

1. Module Name: ENGAGEMENT DATA, NUMBER 3.2.2 

2. Module function: This module supplies rhe data needed 

by the Plan Engagement module to 
generate the engagement plan. 

3. Supervisory modules: Plan Engagement 

4. Module inter face (para met ers) : 

5. Subordinate Modules: Launcher and Missile Status 

Threat Data 

6. Design decision encapsulated: 

************* ************ ^ 

1. Module Name: THREAT DATA, NUMBER 3. 2. 2.1 

2. Module function: Tc provide the information contained in 

the the module to the Engagement Data 
module when requested. 

3. Supervisory modules: Engagemenr Data 

4. Module inter face { para meters) : 

5. Subordinare Modules: None 

6. Design decision encapsulated: 
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1. Module Name; PEOEfiBILITY OF ACQOISITION, NUMBER 3.2.3 

2. Module function: Tc determine whan the probability is 

that if a missile is fired a- a given 
target than the missile can acquire 
and hit the target 

3. Supervisory modules; Plan Engagement 

4. Module inter face (paramet ers) ; 

5. Subordinate Modules: Uncertainty Ellipse 

6. Design decision encapsulated; 

:)c:4e:^:Cc : 0 c 5}c3}c:Sc :4c :«c:jc sjc :4c:4c :0e :0c :4c:0c :4t :}c ♦ :4c * :Jc :4c :0c :0c :0c ♦ :4c * :0c :0c ♦ ♦ ^ * :0c :0c ♦ ♦ :4c:0c 



1. Module Name: UNCEBTAINTY ELLIPSE, NUMBER 3.2. 3.1 

2. Module function: Tc compute the parameters for an 

ellipse of uncertainty around a 
contact's posinion. 

3. Supervisory modules: Probability of Acquisition 

4. Module inter face ( para meters) : 

5. Subordinate Modules: Track Data Base Manager 

6. Design decision encapsulated: 






1. Module Name: DISPLAY, NUMBER 4 



2. Module function: To call subordinate modules as necessary 

tc generate required displays. 

3. Supervisory modules; Control 

4. Module inter face ( para meters) : 



5. Subordinate Modules: Menu Display 

Launcher ana Missile Status Display 
Env ircnmennal Display 
Engagement Display 
Ship Parameter Display 
TJrack Display 

6. Desian decision encapsulated: 
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1. Module Name: MENU DISPLAY, NUMBER 4.1 

2. Module function: To access the Manu/State Data Base and 

display the required menu when called 
and keep track of the state of the 
program . 

3. Supervisory modules: Display 

4. Module inter face (paramst ers) : 

5. Subordinate Modules: Menu/State Data Base Manager 

6. Design decision encapsulated: 
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1. Module Name: LADNCBER AND MISSILE STATUS DISPLAY, 

NUMBER 4.2 

2. Module function: To access the Launcher and Missile 

Status Data Base and provide a display 
of the information contained in that 
data base. 

3. Supervisory modules: Display 

4. Module inter face (parameters) : 

5. Subordinate Modules: Launcher Missile Data Base Manager 

6. Design decision encapsulated: 
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1. Module Name: ENVIRONMENTAL DISPLAY, NUMBER 4.3 

2. Module function: To access the Environmental D^ta Bass 

and provide a display of the information 
contained in that data base. 

3. Supervisory modules: Display 

4. Module inter face (paramet ers) : 

5. Subordinate Modules: Environmental Data Base Manager 

6. Desian decision encapsulated: 
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1. Module Name: ENGAGEMENT DISPLAY, NUMBER 4.4 

2. Module function: To graphically display the flight path 

cf missiles that are no be flown against 
a set target. Threat data on the rarest 
will also be displayed. The sngaasment 
plan will have the caoability ro'be 
superimposed over the'aeneral track 
display . 

3. Supervisory modules: Display 

4. Module inter face (paramet ers) ; 

5. Subordinate Modules: Threat Display 

Aunomatic Engagement 
Manual Engagement 

6. Design decision encapsulated: 






1. Module Name: THREAT DISPLAY, NUMBER 4.4.1 

2. Module function: To access the Threat Data Base and 

provide a display of the information 
contained in rhan data base. 

3. Supervisory modules: Display 

4. Module interface (paramet ers) : 

5. Subordinate Modules: Threat Data Base Manager 

6. Design decision encapsulated: 






1. Module Name: AUTOMATIC ENGAGEMENT DISPLAY, NUMBER 4.4.2 

2. Module function: To graphically display the engagement 

plan that was generated by the Plan 
Engagement module and stored in the 
Engagement Plan Data Base. 

3. Supervisory modules: Engagement Display 

4. Module inter face (paramet ers) : 

5. Subordinate Modules: Engagement Plan Data Base Manager 

6. Design decision encapsulated: 
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1. Module Name; GRAEHICS DISPLAY, NUMBER 4.4.2. 1 

2. Module function: To provide the operator with the capa- 

bility 

tc manually input an engagement plan for 
attacking a given targer. 

3. Supervisory modules: Automatic Engagement Display 

Manual Sngagemenn Display 

4. Module inter face ( para meters) : 

5. Subordinate Modules: None 

6. Design decision encapsulated: 

♦ **♦♦♦♦=)<:» 4* ♦=(t*******!»5»** *♦♦♦♦*♦****:«£* »*»***♦♦ 



1. Module Name: MANUAL ENGAGEMENT DISPLAY, NUMBER 4.4.3 

2. Module function: To provide ~he operator winh the 

capability to manually input an 
engagement plan for antaclcing a 
given target. 

3. Supervisory modules: Engagement Display 

4. Module inter face ( para me ters) : 

5. Subordinate Modules: Graphics Display 

6. Design decision encapsulated: 






1. Module Name: SHIP PARAMETER DISPLAY, NUMBER 4.5 

2. Module function: To access the ship Parameter Data Bas 

and provide a dxsolay of the informat 
contained in that 'data base. 

3. Supervisory modules: Display 

4. Module inter face (paramst ers) : 

5. Subordinate Modules: Ship Parameter Data Bass Manager 

6. Desian decision encapsulated: 
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1. Module Name: TRACK DISPLAY, NUMBER 4.6 

2. Module function: To access the Track Data Base and 

provide a continuous display of al 
tracks being maintained in “hat da 
base . 

3. Supervisory modules: Display 

4. Module inter face { para meters) : 

5. Subordinate Modules; Track Data Base Manager 

6. Design decision encapsulated: 
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APPENDIX D 
HSCLCS ADA DESIGN 



ADA HSCLCS design from [Ref. 2]. 



Package Update is 

Task Launcher-Missile_Status is 

e ntr y Update (Launcher-Missile Status: 

in Status Type) 

End Launcher-Hissile_Status 
Task Skip-Param eter is 

Update (Ship-Parameter: in 

Ship-Par amet er- Type) 

End Ship-Parameter 
Task Environment is 

e ntr y Update (Environment: in Environment-Type) 

En d Environment 
Task Threat is 

en^y Update (Threat: in Threan-Type) 

End Threat 

Task Update-Track is 

e ntr y Add (Track: in Track-Type) 
entry Delete (Track: in Track-Type) 
en^y Modify (Track; in Track-Type) 

End Update Track 
End Update 
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Packa5® Auto-Engagement is 

A -Engagement (launcher-Missile-Scatus: in 

Status type. Threat: in Threat Type, 

Eng agement -Plan : out Engagement- Plan-Type) ; 
Proc edure Prob-cf-Acguisition (Engagement-Plan: in out 

Engagement -Plan-Type ) ; 

Proced ure Uncertainty- Ell ipse (Engagement-Plan: in cut 

Engagement -Flan_type) ; 

End Auto-Engagement 



JSanual-Engagement is 

Proced ure B-Engagement (Launcher-Bissile Status: in 

Status-Type, Engagement-Plan: out 

Engagement -Plan-Type) ; 

End Banual-Engagement 
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Packa ge Display is 

Task Menu-Display is 

Access (Menu: out Menu-Type) 
End Menu-Display 
Task Launcher-Missile- Status is 



e ntr y Access (Launcher -Missile-Status : out 

Status- Type) 

End Launcher-Missile-Status 
Task Environment is 

e ntr y Access (Environment: out Environment-Type) 
End Environment 
Task Ship -Par a meter is 

Access (Ship-Parameter: out 

Ship -Par amet er- Type) 

End Ship-Parameter 
Task Track is 

e ntr y Access (Track: cut Track-Type) 

End Track 
Task Threat is 

e ntr y Access (Threat: out Threan-Type) 

End Threat 

Task Engagement-Plan is 

entry Access (Engagement-Plan: cut 

Enga geme nt-Plan -Ty pe) 

End Engagement-Pla n 
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Packa^S Engagement-Display is 

Procedure Manual- Engage-Dis play (Engag ement - Flan ; 

in out Engagement-Plan-Type, Threat: 
in out Threat-Type) ; 

P roced ure Auto-Engage-Display (Engag ement -Plan : 
in out Engagement-Plan -Type , Threat: 
in out Threat-Type) ; 

P roc edure Graphics (Engagement-Plan: in out 

Engag ement -Plan -Type) 

End Engagement Display 
End Display 
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Package Data Base Managers is 

Pac ka ge Launcher Missile Status Manager is 
T ype Status Type is 
Reco rd 

Enpty : Boolean 

Miss Type: String range A .. C; 

End record 

T ask Launcher Missile Status is 

entr y Update (Launcher Missile Status in 
Status Type) 

entr y Access (Launcher Missile Status 
out Status Type) 

End Launcher Missile Status 
End launcher Missile Status Manager 
£§ckage Ship Parameter Manager is 
T ype Ship Parameter Type is 
Record 



Integer range 
Integer rang? 
L atitude; 
Longitude ; 



Course 
Speed 

Position Lat 
Position Long 
End record 

T ask Ship Parameter is 

entr y Update (Ship Parameter 
Parameter Type) 

e ntr y Access (Ship Parameter 
Parameter Type) 

End ship Parameter 
End Ship Parameter Manager 



0 . . 359 ; 
0. .50 ; 



in Ship 
cut Ship 
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Eackaqs Environ ment Manager is 



Type Environment Type 
Record 

Visibility 
Sea- Sta te 
Wind Dir 
Hind Spd 
Temperature 
Baromet ric 



Re al Range 0. . 30 ; 
Inneger range 0..5; 
Integer range 0..359; 
Integer range 0..100; 
Integer range -100.. 150 
Integer range 900.. 1200 



Task Environment is 

ent ry Update (Environment; 



Type) 

ent ry Access (E 
Type) 

End Environment 
En d Environment Manager 

Threat Manager is 
T ype Threat Type is 
Record 

Ship Name 
Ship Class 
Weapons 
ECM Equip 
Attack Plan 



nvironment: 



String ; 
String ; 
String; 
String ; 
String; 



in 



o ut 



Env ir cnment 
Envir cnm snt 



End record 
Task Threat is 

ent ry Update (Threat: in Threat Type) 

, entry Access (Threat: out Threat Type) 
End TnT?$t 
End Tnreat Manager 
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Package Track Manager is 
T ype Track is 
Record 



Type Track : 
Class Vessel : 
E earing : 

Range : 

Position Lat 
Position Long : 
Course : 

Speed : 

End record 
Task T rac k is 

entry Add (Track: in 
entry Delete (Track: 
e nt ry Modify (Track: 
ent ry Access (Track: 
End Track 
End Track Manager 
Package Menu Manager is 
T ype Menu is 
Rec ord 



Boolean ; 

String ; 

Integer range 0 
Integer range C 
Latitude ; 
Longitude ; 
Inreger range 0 
Integer range 0 



Track Type) 
in Track Type) 
in Track Type) 
out Track Type) 



Undetermined ar rhis time 
End record 

Task Menu Display is 

entry Access (Menu: out Menu Type) 
End Menu Display 
End Menu Manager 



.359; 

. . 500 ; 



..359; 

..50; 
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Eacka^e Engagement Plan Manager is 
T ype Engagemenp Plan is 



Record 

Track Desig 
Type Plan 
Sum Missiles 
Sequence 
Miss Ty pe 



String ; 

Boolean ; 

Integer range 0..24; 
A rra y; 

String range A..C; 



End record 

Task Engagement Plan is 

entry Access (Engagement Plan; out Engagement 
Plan Type) 

End Engagement Flan 
End Engagement Plan Manager 
End Data Base Manager 
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APPENDIX S 

HSCLCS SAHELE SOFTHARE SPECIFICATIONS 



Sample software spe cif icarion s for 
[Ref. 13]. 



Da t a /I n fo r ma ti p p 

la. Surface Contact Position 
(range/bearing) . 

The use of bearing line in 
addition to the 1b requirement 
reduces the number of displayed 
surface contacts by two per 
bearing line. 

-Designated Target 
Target Category and Classifi- 
cation Displayed. 

-Unintended Target (s) 

Target Category and Classifi- 
cation Displayed. 



Req u 
Ba selin e 
10 



X 



X 



1b. Surface Co n tact/ Hear in g Line 



1 



2. Own Ship Position 



X 



5. Air Contact Position 



1 



4. 3rd Party Targeting Data Source 
Designation 

WCIP shall resolve target position 
based on range and bearing input 
from 3rd party or bearing lines 
from 3rd parties or own ship. 



HSCLCS from 

ire ment 

Des ig n Goal 
20 (min) 



3 (min) 

3 (min) 
3 (min) 
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-Manual Entry of Bearing Lines X 

-Manual Entry of Eange and Bearing X 

5. Target Classification 

-Large (default) X 

Larger than a patrol boat. 

-Small X 

Patrol beat or smaller. 

6. Ccntact/Track Course Direction 
Indicator 

Program automatically compensates 
for own ship's motion. 

-Direction Indicator X 

-Dead Beckoning (Cwn Ship Only) X 

7. Ccntact/Track Targeting Data Source 

-Manual Input X 

With appropriate data source error; 
includes 3rd party. 

-Automatic Input 

-NTDS X 

-FAEAE X 

-SONAR X 

-EW/ESM X 

-Target Designation System X 

8. wind Parameters (relative) 

- Speed 

-Actual X 

Manual input. 

-Default value X 

-Direction 

-Actual X 

Manual input. 

-Default value X 



127 



I 



9 



. Temperature 

-Actual X 

Manual input. 

-Default value X 

10. Precipitation 

- Y es X 

Manual input. 

-Nc (default value) X 

11. Operator Cues/Lockouts 

-Launch Inhibited (lockouts/cus) X 

All launch inhibits except roll/ 
pitch cutout. 

-Missile Ready (cue) X 

-Data Age (cue) X 

Target and envircnmenta 1 data. 

-Missile Launch Status (cue) 

-Cell/Eail Empty (missile away) X 

-Missile Dud Declaration X 

-New Contact/Track to be Input (cue) X 

-Illegal Action ( lockout /cue) X 

12. Time/Clcck 

-ZOLO Time X 

Start clock: Autciratic entry via 
NIDS Interface and/or manual entry. 

-Tima on Target X 

Manual entry. 

-Time cf Launch X 

Computation . 

-Ccuntdcwn X 

Includes Time-to-Fire and 
Tims-tc-Impact . 

13. Loadout Status/Missile Variant 
Identification 
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X 



-Eas9lins/Block I Tactical Missile 
(BGM-64A) 

-Royal Navy Submarine HARPOON X 

(EGM-84B) 

When reconfigured for surface 
launch. 

-Block IB Tactical Missile X 

(EGM-aac) 

-Block IC Tacrical Missile X 

(RGM-64D) 

-Supplemental Identification X 

(manual entry: info from Icadoun 
logbocks of hybr id/ncns tan dar d 
seeker-KGU combinations) . 

-Training All-Op Round (RTM-84A/C/D X 

and HNSH) 

14. Missile In-Flight Tracks X 

15. Up to 180 degree Off-Axis Launch X 

QPtlliional Selections 

1. Reference System 

-True Target Bearing/Relative Target X 

Range 

Top of display is north. 

-NTDS Grid X 

-Geographic (latitude & longitude) X 

2. Planned Missile Flight Path 3 

Software to ensure that no flighc WPS 

path may be selected which could 

result in the acquisition of own 
ship. 

3. Search Mode Selection 
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X 



-On Line Sizing (default) w/Hanual 
Override 

On Line Sizing shall be automat- 
ically selected if RBL or BOL are 
net selected, 

-Range and Bearing Launch (RBL) X 

RBL patrern size shall be a 
function of total flight path 
(range traveled tc target) . 

-Bearing Only Launch (BOL) X 

4. Selecrable Search Pattern Expansion 

(0 - 360 degrees) X 

For RGM-84D missile only, applies 
to REI node and On-Line -Sizing 
(OLS) which results in an RBL 
search pattern. 

-Normal Center Expansion X 

Fcr EGM-84 A/BGM-84E/RGM -84C 
missiles; default for RGM-84D 
missile. 

5. Enable and Destruct Ranges BOL X 

Default values or manual entry 
(ranges not supplied over NTDS 
interface) . 

6. High Altitude Hold 
RGM-84D only. 

-No Entry; Default X 

The High Altitude Hold default 
range not to interfere with search 
initiation and not to exceed lOnm; 
i.e.. High Altitude Hold range is 
set tc the minimuit of 1 0nm or range 
to search .initiation. 
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X 



-Manual Entry 

Th€ selected High Altitude Hold 
range must be less than the range 
tc search initiation. 

7. Presearch Fly-Out 

-Sea Skim (RGM-84D only) X 

Default mode - Presearch Fly-Our is 
set to sea skim altitude following 
the High Altitude Hold. 

-Manual Entry X 

Presearch Fly-Out at normal HARPOON 
run-in altitude as used in current 
HSCLCS. 

8. Terminal Attack Mode (RGM-84D only) 

-Sea Skim (default) X 

-Pcp-uc X 

Default override by manual selec- 
tion of pop-up, "SMALL TARGET" 
designation by NIDS, or when 
"SMAII TARGET" is entered manually. 

9. Missile Assignment for Engagement 

Planning X 

Manual entry. 

10. Multi-Missile Engagement of 4 

Designated Target. 

Baseline: Up to 4 missiles from a 
single launcher. (Note: Single 
launcher includes TARTAR and 
ASROC) . Design Goal: Up to 8 
missiles from 2 CML's. 

-Salvo Missiles Against One Target X 

For Simultaneous Arrival (STOT 
Salvo) . 



8 
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X 



Operator-planned engagement. 

-Salvo Against Op to Four Targets 
(single airpcint) From One Launcher 
For Simultaneous Arrival (STOT 
Salve) . 

Same aimpoint and a different RBL 
search expansion for each RGM-84D 
missile in order to distribute 
salvoed missiles among the targets 
in a formation. 

-Hippie Salvo as per current HSCLCS X 

CML Configuration. 

-Quick Reaction/Preprogrammed STOT X 

Salve . 

Modified HSCLCS automatically will 
calculate and enter a different 
waypoint for each RGM-84D missile 
in a guick reaction salvo for 
simultaneous time-on -target (STOT). 

11. Background data and sector data X 

request . 

Dsatle with HTDS interface only. 
ENGAGEMENT D ISP LAYS 

1. Contact/Track Uncertainity Ellipse 

-Designated Surface Target X 

-Unintended Targets X 

If selected by operator. 

2. Predicted Time-on-Targe t X 

3. Probability of Acquisition 
Numerical value. 

-Designated Targets 
-Unintended Targets 
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X 



If selected by operator. 

4. Seeker Search Pattern Outline X 

For selected search mode. 

5. Missile Flight Path X 

For all selected missiles. 

6. Booster Drop Zone X 

7. Missile Power Application Warning X 



OTHER 



1. Test/Maintenance 
-Missile BIT Results 

-Go/No-Go Indication X 

-Failure Status Code X 

-HSCLCS BIT Results 

-Go/Ro-Go Indication X 

-Failure Status Cede X 

2. Training Mode 



Inherent capability provided by 
system design. Design to utilize 
data from RTDS and/or external 
training support devices via an as 
252 serial interface. 

-Ccntact/Track Location (actual or 
simulat sd) . 



-Cff Board Source/NTDS X 

-Own Ship Sensors/NTDS X 

-Manual Input X 

-Own Ship Position (actual or simul- X 

ated) . 

-Training Scenario Parameters 
-Environmental Conditions X 

-Operational Planning Selections X 
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Data Extract 

Design to be compatible with an RS 
232 serial interface to provide for 
data storag s/display in off-line 
devices (e.g., tape cassette recor- 
der) . 

-Target/Targeting Data X 

-Missile Initialization Data X 

-BIT Results X 

4. Major Display Features 

-Variable Range Scale X 

16K-, 32K-, 64K-, 123K-, 192K-, or 
256K-yard radius. The 256K-yard is 
the default scale. 

-Offset X 

-Zoom X 

8K-, 16K- or 32K-yard radius. 

-Special Symbols X 

-Cursor, with Bearing/Range readout X 

Manually controlled. 
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iPPEHDIX ? 

HSCLCS SYSTEH DIAGRASS 



Of 



These four diagrams illustrate the current 
the HSCLCS and the new proposed one. 



nf igurat ion 
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Pigure F.3 Proposed Cannister Launch HSCLCS WCIP* 
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CELL FCS PACO SEARCH SEARCH ATCK LAUNCH 

mode prior mode time 

5 READY .90 DDL NORM SKIM OB s 30: 52 

7 READY ,90 RBL NORM SKIM 00:31:00 
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igure P.4 Saapls Display from Proposed SCIP. 
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